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.
