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.