WTH can we just not template every string in frontend yaml
It would be so great, if every string could be template in frontend yaml in every HA card. A general FR.
With this a lot of custom card overhead would not be needed anymore and it would be soooo flexible, if I would be able to set icons, entities, titles, etc. etc. just as before or via a template.
This would slow down the system exponentially. A major change would need to happen with the template engine to avoid the slowdown and it would negatively affect how templates work currently. This would likely require templates to become async, which would make all the synchronous template stuff break (template entities).
It is not just a performance impact issue; it is also a âwhen to renderâ issue. On config load? On use? Will it update in between?
Weâd get into all kinds of unexpected corner cases if we approach it the way done by (for example) Ansible. For Ansible, it works, as it is run once and finishes, and is not a continuously running process.
card-mod, template config card, ⌠are updating on state changes as well, I think. 
I really donât see that much differences for those who are already using those or want to use this and ofc know that templating is causing some delay but really want to do it.
I take it youâve not seen the folks who are using these examples to extremes and then say their dashboard loads slowly?
For me the whole UI is reacting on state changes, icon, icon colors, state text, state values, ⌠For those who want to react on the âsameâ state changes voluntary (as it is no must) to color or do something else, it would not be that much overhead. And not more than creating a template sensor, which is updating as well and use this one in the UI instead for having e.g. another value displayed.
I understand being defensive here. But perhaps with some limitations and as a starting point it would be still a good idea and as least some have voted as well. Thought that is more like a idea gathering and not directly augmenting down ideas. 
suppose âevery single stringâ is a bit wild, and not very succinct.
maybe start with those that really could benefit. Arganto mentions several important ones:
Since changing state values has proven dangerous in the past, I would not advocate those from being templatable. Too easy to get lost/stuck.
Entity_picture otoh though would be magic (example usecase: grayscale when not_home, color when home).
or in yaml:
homeassistant:
customize_domain:
person:
templates:
entity_picture: >
var id = entity.entity_id.split('.')[1];
return state === 'not_home'
? '/local/family/' + id + '_not_home.png' : '/local/family/' + id + '.jpg';
Another effective option, which wouldnât even require templates, would be to set several hard-coded properties as theme variables.
Take the badge icon size, which is way too small for older eyes. just let the user set a
ha-badge-icon-size variable in their theme and all magic would be done.
By presenting this as an initiative to gather the most sought-after customizable properties, we could successfully communicate the benefits while addressing potential concerns about system overloading.
I believe this would fit here as well: WTH tooltips / drop-downs for inline documentation of dashboard elements
And this one?
I would like to be able to use templates on tile cards.
For example, to add the plug consumption to the switch entity
My post titled âTemplates on Card Tilesâ has been removed. I believe it is not exactly the same as what is being requested in the other post. It seems unlikely that this topic will be addressed in the same way.
@tom_l, could we recover the closed post?
Please donât take offense to WTHs that are closed, we consolidate them to ensure voting is accurate. The WTH in question falls under this WTH. Both are requesting templates in fields, the other WTH is just requesting templates on the tile card fields.
Donât worry @petro, Iâm not offended. I understand that rendering templates for all YAML strings might not be feasible. However, having a specific option for the Tile Card, similar to the templates in Mushroom, might be a viable solution.
There have been many discussion in github on a core equivalent to mushroom template card based on tile.
I am not sure it will happen, the dev seem to want to keep Tile simple for beginner, thus mushroom might survive, at least for the template card.
I would love to see more templating available in core cards, but my hope are now prety low⌠Voted anywayâŚ
Adding âTemplateâ as another option for the state content wouldnât, in my opinion, add complexity for beginner users. Beginners likely wouldnât use this option, just as they donât use the code editor.
I currently use Mushroom, but it lacks the beautiful animations that the Tile Card does have.