[Opinion] Has the Time Come to Rethink HA’s Approach to Custom Cards?

[Majed-BX]

Introduction

This opinion stems from direct experience and active feedback from the Home Assistant community.
It is not a formal complaint or technical issue, but a calm call to reevaluate how Custom Cards are treated architecturally within Home Assistant.
Due to my limited availability, I may not actively follow up on replies but will try to respond if I have something valuable to add.

---

1. Are custom cards really that important?

Yes, without a doubt.
Custom cards like button-card, layout-card, and auto-entities have transformed Home Assistant from a basic automation platform into a flexible and creative environment.

Result:
Without them, the UI remains classic, limited, and lacking in visual and interactive customization.

---

2. Do custom cards offer more flexibility than official ones?

Absolutely.
Official cards don't support JavaScript templates or Jinja2 — except for the markdown-card, while custom cards offer powerful templating capabilities.

Result:
This makes custom cards far more capable of creating rich and dynamic UI experiences.

---

3. Can Template Sensors fully replace custom cards?

No, not at all.
Duplicating logic in YAML for every display case undermines the “UI-first” principle that Home Assistant claims to support.

Result:
Custom cards remain the simpler and cleaner way to present dynamic display logic.

---

4. Is it normal that official cards still don’t support JavaScript or Jinja2?

No, especially in 2025.
Modern UI systems rely on built-in templating. The lack of this in Lovelace official cards makes customization tedious and limiting.

Result:
Allowing this — even partially — could eliminate the need for many custom cards.

---

5. Should some widely-used custom cards be officially adopted?

Yes, definitely.
Cards like card_mod are core components in many advanced dashboards, yet remain unsupported officially and lack official alternatives.

Result:
Adoption or official alternatives would reduce risk, increase stability, and boost user trust.

---

6. Does ignoring custom cards hurt system integration in the long run?

Yes.
Making core-level decisions without assessing their impact on third-party tools undermines the system's visual and functional consistency.

Result:
Frequent breakages post-update turn Home Assistant into a platform of surprises, not reliability.

---

7. Does the Home Assistant team consider custom cards in architectural decisions?

No, clearly not.
A direct quote from karwosts:

"Custom cards are not considered when decisions are made for HA architecture."
(Source: GitHub Discussion Comment)
This means custom cards are excluded from core architectural planning.

Result:
This direction creates a trust gap between developers and the platform, leaving their tools vulnerable to breakage.

---

8. Is the issue really about a specific change like display_precision?

No, the issue is broader.
The concern arose from the clear public statement that custom cards won't be considered in future development.

Result:
This sends a negative signal to the community and questions the platform’s support for long-term continuity.

---

9. Is it reasonable to ask the team to officially support every custom card?

No, but structured coordination is feasible.
We’re not asking for full support, but rather an open policy that includes delegation, shared maintenance, and compatibility monitoring.

Result:
Important cards could continue to evolve without burdening the official team.

---

10. Could this direction actually threaten Home Assistant’s future?

Yes, over time.
Trust between the community and the core team is essential. Once broken, alternative platforms will begin to grow.

Result:
Losing trust in community tools may lead to fragmentation and migration elsewhere.

---

Conclusion

If Home Assistant wants to continue being a truly open and creative platform, it must respect community tools — even if unofficial.
Having a clear policy and managing the relationship with custom cards is key to maintaining trust, ensuring quality, and securing the platform’s leadership.

[tomlut]

There’s no way HA can support all custom cards.

There's no way HA can consider the impact of changes on all custom cards.

Structured coordination exists. Changes are announced publicly beforehand. Anything else would be too restrictive for custom card developers.

If you have an issue with a card then open an issue with the card developer and also ask them to watch the home assistant developers blog where most changes are announced beforehand.

[BBE-FR]

While on one hand I agree with @tomlut tomlut above and understand that there is no way that HA can consider all custom cards,

On the other hand I observe also that for a huge number of user our dashboards are relying on many custom cards. Thus I fully support @Majed-BX to at least open the discussion !

For my specific case, while my dashboard is very close in look to the new area Dashboard, relying mainly on tiles and header cards, I am using the following cards as the foundations of my dashboard, thus any disruption is a major issue:

• Mushroom (mushroom template card) for the Jinja2 templating not offered by tile cards
• vertical-stack-in-cards to create customisable "area cards like" because area card are too constrained
• card mod (for some adjustments of position / margin / padding due to the use of stack in cards)
• browser-mod (only for the pop up capacity).
• auto-entities to dynamically create list of cards (but this one could be avoided if needed)

5. Should some widely-used custom cards be officially adopted?

If like suggested by @Majed-BX some more advanced features could be incorporated into the core, that would (to my opinion) be great. In my Dashboard, having in the core:

• a few card allowing Jinja2 templating (with the Tile look for exemple)
• a capacity to stick together a few cards (basically the vertical, horizontal or grid existing cards, but with a common border and background to create your own "fused" card based on existing cards)
• a way to create pop up, for exemple with a customisable "more info"

These 3 features alone would reduce the custom cards usage to only genuine "advanced" features like auto entities, streamline templates or specialized cards.