not right.
more features, and active maintenance. many other advantages in the background, among others the issues many users saw when double loading card_mod.
reason for developing this new integration (another new feature and advantage) is explained in the repo
yes, a new keyword. this right, but from the perspective of this integration, not optionalā¦
of course, it is optional to migrate, anyone can choose to move to Uix, or not.
Can you please elaborate more?
Where are the more features, you are mentioning? Canāt find.
Why is the keyword not optional? It is described that it still works with old keyword. Why do you state the opposite now?
The only reason, I read, is fixing the double loading. But I mentioned this as the difference of course.
@arganto That UIX seems as this to you means it has done its job well.
Brings over features that can have a proper home without any conjecture of what card_mod is and should be in or out. Also, UIX is 2023.3 ready with upcoming dialog changes. 5.1.0 beta adds toast support. 5.1.0 will also fix up ha-svg-icon which is not child of ha-icon, often used when Frontend uses ha-icon-button with specific svg path.
While UIX has heritage of card_mod it is not uncumbered by it, and there will be lots more to come.
Not the only reason, but again a good reason, and as I said before, multiple pages of documentation on that one topic justā¦ goneā¦ 
Oh, and whole new doco site. 
https://uix.lf.technology
To be clear. I loved the old extended card_mod, I will love the new integration and I read already the documention. And I dont want to do criticize. I really only wanted to compare the as is from today.
And because my summery above, which is already a more than good starting point. The less breaking changes, the better
But then such answers from Marius is misleading. Yes, there will be new features. Great. But for now I didnāt see them. What is fine, but I just wanted to know this. Beside the other most probably wrong answers, like the keyword (at least for now). During intrudocution of this new repo it is not helpful and it is confusing more.
I am not sure what you mean here and what was confusing.
You are writing in the docs, that (currently) the change of the keyword is optional. Marius is writing, that it is mandatory. At least one answer is wrong. And ofc this is confusing then.
No performance hit is expected. I assume you came from v4.2.1. There could be a very slight loading difference as uix.js is not gzipped, but I donāt believe that is what you are describing.
UIX will check for uix: keys first in config, themes etc. before checking card_mod variants. It is plausible that there is a call there that is expensive performance wise and is showing in your environment. Can you submit an issue with details and we can keep reviewing. Thank you.
Itās simple. The new integration uses a keyword uix:
And is also accepting the card_mod: keyword.
As a service to the existing user base, meanwhile encouraging to change to uix:
Edit:
Sorry, cross posted with above
Quoting from docsā¦
Is UI eXtension a drop in replacement for Card-mod?
Yes, UI eXtension is a drop in replacement for Card-mod versions up to 4.2.1. All Card-mod card and themes configurations are supported. While you are encouraged to update to useuix:in your cards anduix-<thing>(-yaml)for your themes, it is not required.
As said. I read this. I wrote this. But then Marius wrote ānot Optionalā what means mandatory. This is the only thing I wrote.
Providing some more context here. Currently UIX is for managing CSS style injection at all levels of Home Assistant UI in the most generic possible way. On ther hand, Browser Mod provides lots of specific customisations that adjust the Browser or mechanics of Home Assistant UI. e.g. to get more-info large, there is no way but to set the large property on the DOM element once it is ready. So Browser Mod needs to catch the hass-more-info message, wait for the dialog, then set large. Moreover the hass-more-info message params does not include large, otherwise it may be pretty simple with any JS plugin, like button-card.
I was just asking if UIeX was potentially āfasterā than card-mod when in use on the dashboard page/view. Any improvement in performance is appreciated since HA dashboards are very slow even on mid-level tablet CPUs. Iāve moved most of my logic and layout building to templates.yaml and the pages are still very slow to load/refreshā¦ almost unusable without a higher-end ($300USD) android tablet.
On the same tablet thoughā¦ Music Assistant runs fast and so does Advanced Camera Card with 10 live streaming 2k streams. So I suspect the issue is how the dashboard renders the page elements and the sheer number of different things it must render/calculate, often even in the same single card (DOM rebuild cascades, JS templates, Style application then reapplication, etc)
Understood. One check is to run your environment without any plugins by restarting in Safe mode. If everything still grinds then its more to do with your Home Assistant and state updates, in that you have many frequently updating states. There are many threads about the topic that go into depth.
Next would be to check through your custom cards. Some can be quite inefficient in updates. e.g. If you are running auto-entities 1.16.1 it is problematic, switch to 2.0.0.
I expect you will find its one of the above.
will the extension also be added in the āofficialā HACS store?
Yes to HACS once Home Assistant brands PR has been merged as this is required for HACS. Also, once that is done you will no longer see just a generic square for UIX in Home Assistant.
hmm seem to work mostly to get rid of card_mod: entries ā¦ but my apexcharts do fail and still require it. Perhaps I need to update that one?
apexcharts_card either needs config below or to keep card_mod until apexcharts_card is updated. See [Bug]: custom:apexcharts-card gives config validation error Ā· Issue #55 Ā· Lint-Free-Technology/uix Ā· GitHub
experimental:
disable_config_validation: true
As long as card_mod: is sort of aliased being equal to uix: I wouldnāt even call it a bug. But that surely depends upon the question for how long old school card_mod: entries will be kept supported or fade out in UI X some day.
Is this another repo you have ātaken chargeā over ?, i thought i was on latest ( which i am in Thomas-L ) in HACS, but is this 2.0.0 the continuing-story ?
Check out this thread which details the list of issues included in 2.0.0.