Hi. I need some advice on choosing between LiveView and Vue.
My team’s current tech stack is Elixir, Phoenix, LiveView, and Vue. I find it increases the cognitive load of each of the team members to maintain LiveView and Vue together. IMO, we don’t fully utilize each of the technologies. Therefore, I have the idea to focus on either LiveView or Vue. Personally, I love to write in Elixir and choose LiveView means reducing the learning curve.
However, I have one concern about choosing LiveView. There are many libraries we can use with Vue. But, with LV, we require additional efforts to develop.
Does anyone have experience on fully using LiveView on your development? Would love to learn from your real-life experience.
I think it really depends on what the requirements of your project are.
if you only need some custom form elements or validations, etc. then LiveView requires a lot less boilerplate than Vue to do the same things.
However if you want to build a Single-Page-Application, require interactions with complex JS APIs like the canvas, video or audio elements, or need pages to keep on working if the user goes offline, then this falls outside of the feature set that LiveView provides.
I also think it depends on your project requirements. Try to think of something you need that LiveView is not able to solve, then you have your answer.
I would say it does not require interactions with complex JS APIs, but we do require to integrate with different 3rd party services, like Storyblok (Headless CMS), LaunchDarkly (Feature Flag Mgmt), etc.
I wouldn’t use both together. Keep in mind that with LiveView connection latency will effect user experience if server is far away from user. It will also demand more from server because more code is running on server also it’s keeping state in memory for every connected user. I think client apps are more scalable.
I would go client app route if you are creating normal user facing app. If you are creating intranet app for some company or app that is only used inside one country LiveView could work.
Are set on Vue? I think React is more popular and it will make easier to hire people who are experienced with it.
I also watched video about Svelte the new fast UI hotness. Looked quite interesting how it does minimal DOM changes and at least from that video it seemed you could create UIs very fast with it. Video about Svelte is here https://youtu.be/OyFI-zOrKSk
You should also look into creating API with GraphQL. There is excellent toolkit for GraphQL in Elixir called Absinthe. Its website is here http://absinthe-graphql.org/
I have extensively used Vue and I would not pick it again for apps frontend. I wouldn’t pick React or Angular either, though, since more or less the cognitive complexity is the same.
LiveView is great but has some limitations: your app won’t work offline, so if you want to use LiveView and target a mobile platorm with offline capabilities as well, you’ll need to make an app with either Kotlin, Flutter, SwiftUI or similar tools, because LiveView also negates the possibility to port or share part of the JS frontend code with things like Ionic, etc.
In these cases, where you know two tools are too much, but you are unsure which one to pick, I find it’s often a sign that neither is the right answer and you need to look for something else that is more specific to your use case.
Personally, I’d pick LiveView only for very well scoped where you can be sure it’s going to be ok and I’d pick a JS framework only if it’s absolutely necessary.
I prefer the complete separation of server and frontend code. I have just looked into surface-ui, interesting but still just cannot tolerate all that HTML code in Elixir files. For me, Elixir and Phoenix are great on the backend. For the front I prefer Vue. Interesting to hear [some 4 years on] any updates / experiences from fellow developers on the topic
just cannot tolerate all that HTML code in Elixir files.
Interesting, for me this is the best part - having all FE in one file - html, css, js. BE is another file, context.
Simple, elegant. It seems you’re used to the old way, but I would argue the new way is the better way. Surface brought this in and it could’ve stayed that way, yet the phoenix team integerated it to phoenix. I’m glad they did, I feel it was the right call and is in accordance with all the previous decisions. DDD affords least cognitive load and that’s the second line on which to seperate code by, anything beyond that is unnecessary IMO.
I’ve only created small project with LiveView but two things that you can’t get with Vue. First is that you don’t have write any kind of web facing API and you do less database call because everything is basically in same request. Not to forget lot of saved development time from this. Second it’s really easy to sync realtime browser elements between clients. I created this RPG helper that needs to keep every client in sync, meaning everyone needs to see same things in their browser. I just used Phoenix.PubSub at server side and it worked like magic.
Given there is not a viable UI component framework for Phoenix currently that makes it the hard road.
If you look at React, Vue or Svelte then you do have viable UI frameworks to build web applications.
I am in the middle still and experimenting with custom elements aka web components along with live_element to help with event forwarding. There are quite a few web component libraries out there providing nice custom elements and theming and these are also not front end JS frameworks and work just like html elements but can do fancy stuff on the client. You can literally wrap anything in a custom element very easily so I think this gives the live view architecture quite a leg up in what can be achieved.
I also looked at live-svelte as an option but it has several serious issues with nested components which kind of killed it as a viable approach.
If I was to go full client side JS, my pick is SvelteKit with Shadcn-Svelt as my for UI. Of course you have Devs skilled in Vue so it makes sense to take that path.
I also like regular Svelte (which is distinct from SveltKit) because it compiles to minimal code for surgical DOM updates and is very streamlined in how it works with practically no boiler plate. I think wrapping Svelte components as custom elements / web components is a nice way to enhance LiveView using a disappearing JS framework and I also like Lit Element as a way to wrap anything and for implementing custom elements without a JS framework.
So in summary I think web components are the future, JS frameworks will evaporate to bare minimums to reduce boilerplate for PWAs, so routing, state management and support for theming, styling and animation.
Even Adobe have bet the farm on web components with their new design language and web component library Spectrum 2. Also Microsoft have built their Web App Store using Shoelace web components.
Yes that meets the definition of not a viable framework.
It bakes in theme and style
It’s not semantic
Design tokens?
Doesn’t focus on compliance with accessibility standards which are generally a requirement nowadays for anything not hobby related
Keyboard navigation?
it bakes in the CSS framework
it is a funnel to commercial offering.
It is not something the community can rally around
We are left with the stop gap of core components for the generators as the best we got and being a maintenance issue if you use them. They are insufficient for any typical application use cases.
I stand by what I said there is not a viable UI component framework for LiveView and it’s left two options moving forward which is to use a mature set of custom elements / web components or go fully JS front end.
I am experimenting with trying to keep Liveview but it’s basically on life support and I might just go with a Svelte solution because it’s quicker and supports more flexible use cases.
In my mind it’s almost an existential crisis for LiveView. Without a viable set of headless accessibility focused UI components LiveView can never be the productive path to building web apps that don’t have appalling usability and inefficient development. The time to an accessible, themeable, navigable app shell with all the trimmings, authentication, notifications, should be minutes. That’s what you’re up against vs a productive JS front end.
If you are doing hobby projects and tinkering then practically anything will be fine, but the regulations in many countries to have accessible applications and to be commercially viable you have to deliver on the table stakes which LiveView currently doesn’t.
Please don’t be condescending. Most people here do not play with hobby project and do real work
We know from the start that liveview cannot fit all situation, and cannot compete with JS frontend (offline mode, service workers…) but JS world is far from being perfect and It adds complexity. Liveview is simple to integrate and fits some usecase, maybe not yours
Any JS UI library could be written with liveview components, it is just HTML, JS and CSS
Liveview did not even hit version 1.0. It’s unfair to compare with long established JS framework
.
