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 
acrolink
1
ken-kost
just cannot tolerate all that
HTMLcode 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.
1
wanton7
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.
4
adw632
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.
1
tme_317
There is GitHub - petalframework/petal_components: Phoenix + Live View HEEX Components · GitHub which is what I’m using. I’m sure it’s not as full-featured as some of the huge React, Vue, etc component frameworks but it is viable enough for my use case.
0
adw632
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.
7
ryanwinchester
D4no0
I dream of the day when we will stop designing interfaces like cavemen in html+css and have an all around great visual tooling.
3
kokolegorille
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
8
tcoopman
You emphasized the funnel to commercial offerings but are arguing that liveview is only for hobby projects? And doesn’t work for commercial applications.
Surely if you’re building a commercial application, you’re willing to pay a license for an important part of your stack?
I didn’t evaluate the rest of your response but this stood out to me.
0