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.
No I am not saying that. I am saying that when you are doing hobby projects anything will do but when you are doing commercial projects things like accessibility are table stakes, as in if you don’t meet basic accessibility requirements that are codified in various regulations you don’t get to play.
Elixir does not have a LiveView UI component library, not one that has any focus on meeting accessibility requirements. There is one in the making Doggo which I have encouraged as addressing a huge gap.
I am willing to pay and have evaluated a number of libraries including Tailwind UI which was also not a good fit for Phoenix as in there is a lot they don’t provide in the html version that which is addressed in their React components.
The petal components also don’t meet requirements so no I wouldn’t pay for something that is not headless semantic UI with first class consideration for web standards accessibility, keyboard navigation and themeable second.
I am not ok with not addressing a11y concerns and Phoenix has a gap that currently can only be addressed by solutions outside of its ecosystem which means a11y web components or building the UI with a JS framework.
Hopefully my response above explains the context of my statement, which I thought was clear. Hobby use can get away without meeting accessibility requirements.
I am trying very hard to use LiveView for commercial applications. I haven’t given up on it yet but it’s not the front runner it once was.
My statement was directed at the lack of viable UI components for commercial use in countries that actually care about vision impaired where accessibility regulations are applied and enforced, as in you commit an offense for discriminating and not providing workplace software and tools that meet standards and disadvantage those with disabilities.
Do you disagree?
I think you are perhaps being a little too precious. Something is either objectively useful tool for a use case or it isn’t. Version labels are arbitrary.
Being particular about the specific use case and identifying the gap that exists and even positing potential solutions is not complaining.
I am certain anyone who needs to get a UI up and running quickly and discovers there is no decent UI components in Phoenix or someone who has to meet accessibility requirements will just breeze on past without a second look perhaps not even uttering a word.
However, they might just find these posts googling and see a potential solution by someone who had the same use case and didn’t just breeze on past and was bold enough to utter the words.
Technologies thrive or wither based on their utility and the ecosystem that grows around them vs other tools and ecosystems that may offer different or similar advantages. Economic forces are always at play.
The LiveView idea has some compelling aspects and as a technology it has some promise, but it also lacks a lot that is needed right now to be net productive whilst meeting the table stakes of many markets.
Well I have provided some reasons and some gaps that currently exist, so no LiveView is not 100% not even close.
LiveView was indeed the first choice but it’s no longer the favourite. I haven’t given up on it but I’m not seeing the net benefit vs the alternatives despite all the hopes I had for it’s viability.
Things may of course improve and I will continue to consider LiveView for some use cases.
Well that’s what they do with other frameworks. The designers use things like storybook and merge to close the gap and risk between design and development using UI components.
They have evolved to having Netflix, beer fridge, a pool table and aircon, a different kind of man cave.
I’m not a big fan of these online editors, the last time I tried some of them, they were absolutely primitive and hard to work with.
I would like an editor that would be similar to things like WPF, the UI builder from android. I know that they are not that advanced in terms of nowadays requirement, however building UIs in them is blazingly fast.
It sounds like if You use Liveview You are not professional 
For me it is useful, because customers are expecting reactive UI more than accessibility
I disagree
Accessibility is completely possible with Liveview, it’s in the HTML
Mentionning version is about the lack of component libraries, it’s new (0.20)
I do not disagree
You need to build your components yourself
I would prefer to use a JS frontend for a complete control, but the reality is I use Liveview and customers are happy with the result
BTW I am not using Phoenix for UI library, but for OTP
Happy XMas
Anything computational is possible with a Turing complete langauge. But I never said anything is not posisble. 
Any string manipulation can be achieved with unix split and cat. Accessibility is just html strings and is therefore possible with Unix split and cat.
While we are at it and no-one needs an editor like vscode or neovim as split and cat can do any string manipulation required in a file.
You can also build a computer out of nand gates, but even more importantly you can do machine learning with an abacus given enough beads and hands.
Based on the argument of doing things from first principkes we should all be using the minimalist Turing complete brainfuck language to at least not require so many beads and hands.
The unfortunate fact is there is no viable Phoenix UI component library nor one that does accessibility in accordance with web standards the gap exists.
It’s over a year old and little has materialised.
Practically everything else out there for front end work has a viable UI component library that handles accessibility. I think Phoenix LiveView is kind of an outlier in that aspect, along with our trusty friends, split and cat.
I don’t want to spend months getting accessibility and keyboard navigation perfected, nor building and maintaining a UI component library. It is just not viable from a business perspective to do that when I can be delivering actual customer value with viable technology that exists today. That is the objective measure of any tool in business.
Inpired by the words of Roger Penrose, I prefer to not create an actual universe just to make an apple pie from scratch.
I would actually prefer to not use a JS framework. I want to use LiveView but there’s a huge gap that you don’t want to acknowledge or hand wave away. Getting the job done in the most net efficient way, I have to use an external framework because LiveView just doesn’t do it (yet).
Merry Xmas, it’s actually Boxing Day, the 26th here.
Yes that is why I use Elixir, the foundations it’s built upon.
LiveView was a curiosity which I hoped could make things quicker to develop but it’s turned out to be quite the opposite in fact.
It did for me. It’s unfortunate we do not share the same experience
My dream components are wasm powered web components… It’s completely portable and quick
Merry Boxing Day
Are you hoping that all your posts about how liveview is not up to scratch (and svelte or web components are the best choice) motivates someone to do this for you? And for free?
Your comment is quite out of place and deliberately antogonistic.
If you have actually read my posts I have been experimenting with a number of solutions both within and outside the LiveView ecosystem including live-svelte and live-elements with various web component libraries as a way to use LiveView and get both acccessibility and polished UI efficiently.
I have been doing this myself not waiting for anyone.
I have been quite positive in respect to Doggo which may close the gap and ought to be something that gets adopted as a core Phoenix component library to replace core components which is the biggest eyesore in the Phoenix ecosystem and will continue to hold back Phoenix from being used more widely. It is grossly insufficient, bakes in UI design colours and styles and creates a maintenance issue if you touch it.
I am being vocal about the issues because unless it is recognised that Phoenix needs a headless semantic component UI which focuses on accessibility and keyboard navigation separating theming and CSS frameworks then there is nothing for the community to rally around. No ecosystem for tools, theming and CSS frameworks and web site templates. Missed opportunity.
Based in your feedback and what is available today for LiveView it would appear the nominal expectations on productivity, accessibility and strict adherence to web standards, keyboard navigation and general UI polish is not anywhere at the level vs other front end ecosystems. This is a statement of fact because it is based on evidence, not intended to offend, just to point out the facts as they currently stand.
It is what it is. Whilst LiveView is not there yet, it may get there but right now, when you have to deliver an outcome as I have explained the more traditional route with an API and a JS framework is the only option vs building out everything from scratch.
If the community does not realise it really does need to have to have a viable headless UI component library with accessibility baked into the core, along with theming and style add ons then my prediction is that adoption of LiveView will remain fringe at best and the jobs market will continue to be tumbleweeds for Phoenix developers.
I will be hiring additional developers for both front end and backend work in the new year. I can promise you it will not be Phoenix LiveView developers for front end work because of low productivity and no viable UI components that meet accessibility standards.
So to your point, I am not waiting for anyone and I am spending my money to build a development team to solve customer problems. I am doing what I need to do, and pessimistically not expecting the community to do anything actually and continue deny the gap exists, make pithy remarks as you and others have done.
I have highlighted the gap and decisions that have led to saying “no thanks” to LiveView for the time being. This does impact the community if it wants to remain viable as others just like me will take a look, and then realise this ain’t ready, and quietly breeze on by.
So there you go, market forces at play, the community just lost some adoption and job market share, and like me others will make the same judgement call based on not solving table stakes problems.
You may disagree but when accessibility is not optional where customers cannot buy your offering and procurement evaluations test for it, then what choice do you have?
Besides any commercial realities it is the morally right thing to provide fair access to those with disabilities, screen readers and other vision related conditions, whilst continuing to ignore it as some kind of “outlier use case” is a big part of the problem. It must and should be considered table stakes for LivewView to survive.
Absolutely, the future is web components and wasm may open up writing elixir components for the front end. I have my eye on Hologram which I commented on here and which could provide a pathway to wasm web components written in elixir via transpilation to wasm via the LLVM based emscripten.
Another option is “just” porting the Erlang VM to target WebAssembly. One possibility is using the zig wasm compiler which can compile zig and C code which Erlang VM is written in. There is also WASI that provides a standardized method for importing libraries such as POSIX compat libraries which could support such a port. Not going to lie that it will be a large bundle for a typical release so direct transpilation of Elxir code is probably the best way forward.
Zig is already making progress with wasm here.
Another possibility which has some impressive POSIX coverage is WASIX which could make an Erlang port to WebAssembly quite feasible.
And follow up from Phoenix author Chris McCord, Aug 2022:
Yes, I’ve read your posts. I don’t see anyone denying that there is no headless UI library for Phoenix. My point is that you’ve identified this gap and are dismayed that someone or some company has not solved this problem for your already. You don’t want to do it yourself, pay for it to be done or pay to use one. That seems a little entitled to me is all. Considering your stance, the pre-1.0 status and tradeoffs of LiveView, I’m sure you can understand why it is not done yet.
I don’t think you understand to intent of my post. It is about the gap that exists which really does need to be addressed for Phoenix to remain viable in an ecosystem that often must provide accessibility out of the box.
I am not complaining that the community hasn’t somehow meet all my needs which you continue to insinuate.
I have been using my own resources to experiment with web components to close the gap and will be providing some sample apps for others to follow if they wish to go down that path also. Thats me, not someone else.
So far I have experimented with Shoelace, Adobe Spectrum, and the most recent is Carbon Design System v11 which is by far the best so far and the front runner for a LiveView solution.
Carbon does accessibility very well as the framework has strong design principles. It also provides the essential navigation elements that all the web components lack.
Carbon web components gets as close to parity with a JS front end that LiveView is likely to get in terms of interactivity and accessibility currently, to the point it would likely be the same choice of components with JS Svelte or React or Vue as well.
I will be sharing a starter project on using Carbon with Liveview.
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:
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 think that this is the similar threat level as an HTTP API leaking data, because in a production application you will never run code from an untrusted source, meaning that someone has explicitly written that leaking code at some point.
I agree that liveview is complex, but so is having 2 separate applications written in different frameworks.
The biggest problem I see currently to liveview becoming more abstract and easier to use is the fact that we have to reach for the frontend, the server-side interaction and functionality we have is not enough and most probably will never be.
As liveview gives rendering control to the server, this is a direct tradeoff of things that you cannot do without the server. A simple analogy would be streaming videos from youtube, you don’t have to download entire videos or have storage for that, but without internet connection there are no videos and a slow connection will not be good enough to watch it in realtime. I would also add that liveview is not that different from how a web application behaves comparatively to a native one on a machine. We trade native capabilities for a unified way to render and process things in a single application, adding hooks and JS basically breaks that behavior at the cost of complexity.
Yes, I think the levels of complexity are roughly comparable, just distributed differently.
I think Key number 1 is web components. These offer the right kind of balance. We can get rich UI experiences in a framework independent manner.
Key number 2 is to use a capable design system which provides a comprehensive design language that covers off every conceivable design consideration be it colour, accessibility, navigation, layout, flow, feedback, motion etc.
I’ve been deep diving into the Carbon Design System which offers React, Svelte, Vue, CSS and Web Components. It is a capable design system that I can hang my hat on (more on this later).
In Carbon the JS front ends are all just thin wrappers on the web components. (Key number 1).
I am also following a similar path for LiveView by wrapping components with a thin function component wrapper. I am also toying with automating the Phoenix component wrapper generation by leveraging CEM - Custom Elements Manifest. CEM provides component metadata such as properties, attributes, events and slots, perfect for generating Phoenix function component wrappers.
So with JS front end and LiveView it is essentially the same complexity thus far but considerably more work on the Phoenix side vs an out of the box experience with JS front end. So the front end JS frameworks win here.
The next part is that a front end requires both a router, an API interface and state manangement which can be quite a chore and a key reason we like to avoid JS front ends.
In a LiveView backend we have a similar chore interfacing with our domain via contexts to fetch and update data but we do get to cut out the middle API layer. Phoenix backend wins here.
The best solution I have seen on the front end is Houdini GraphQL which was developed for Svelte and also recently implemented for React. It unifies the routing, the state management and API together in a very nice declarative fashion. There is still some effort but it’s a major improvement:
At this point to support the front end you are now dealing with vending a GraphQL interface on the backend instead of LiveView.
In my case I have been experimenting with the Ash framework which streamlines the whole backend development including domain model, querying, actions, schemas, migrations, JsonApi, GraphQL, and an awesome access control policy engine integrated with resource actions and query processing.
The effort for using a JS framework is now a lot less and quite compelling. While I still have some API to describe, I don’t have to build component wrappers or write LiveView glue code to my contexts/domain model.
Given I am adopting the Carbon Design System I have many options for front end JS and server rendered available. I get to leverge IBMs considerable investment in UI research and development along with some incredibly detailed design guidance.
All of this is important for my service as I want others to be able to integrate and ensure their extensions can use whatever front end framework they please, be it Vue, React, Svelte, Angular, Web Components, or just HTML+CSS and still get a consistent look and feel with accessibility plus I can defer to the comprehensive Carbon design guides for the detail.
Carbon is also something that is likely to have traction with it being one of the top UI design systems out there.
The chocies I am making provide flexibility a level of stability and insurance against potential future churn:
The design system being agnostic to the technology, allows me to pivot from backend rendered to front end JS using Svelte, Vue or React. I can also do this without any redesign to the user interface or impacting user familiarity. I can even do it in an incremental or hybrid fashion converting view by view where it makes sense.
I hope that provides some insights into making these kinds of decisions.
© Copyright Elixir Forum | Terms | Privacy & Cookies
