I have been slack about implementing Lovelace, and feel I am really way behind in my understanding. I see beautiful implementations and want to get started.
Anyway it seems my first choice is whether to use a yaml config, or use the ui lovelace config tool.
I am a bit of a control freak, so I am rending to favour yaml. But some guidance is appreciated.
I use both and cut/paste the yaml into raw mode so HA is configured for GUI mode not yaml. I will use the GUI to see how style changes look etc. I also can cut/paste from yaml to the raw editor and I don’t save the yaml until I know I didn’t screw up… So the benefit is I can just go back easily and I can see changes instantly in the GUI if I want to… but it’s purely a personal preference.
I’d recommend you try the UI first. There’s nothing that can’t be done there, and it’s the simplest and fastest way of making changes.
I’ve been using Lovelace since it was all YAML, and still use YAML, but that’s inertia more than anything else.
Except that…
Agree on both points but the GUI is useful for immediate feedback.
Fair point.
To expand on the comments issue though, to be clear this is no just about the usual comments to explain what is going on or delineate sections (although they are useful).
It is very rare to see a post of Lovelace code on this forum with no lines commented out which leads me to believe that I am not alone in wanting to keep various options rather than deleting them when tinkering with the code.
I’ve never used the UI so I don’t know if it reasonable to expect but I really think comments need to be allowed.
Not only comments, but includes are also not supported in the GUI. So if you would like to have !secret in your lovelace then you will need to have yaml mode enabled.
This is particularly useful if you share your config on github and has important information that you don’t want to share (like locations or email addresses for example).
Personally I prefer yaml mode as I can leave it open in a text editor. Changes done via the editor will be applied immediately after saving, it only takes a refresh to show the changes. Though the UI is probably a lot easier to use.
I’m using yaml on my productive HA and sometimes playing with the UI Editor in a test hassio vm.
What i hate is the sorting of the yaml in the Raw Editor, absolutely confusing.
For simply adding/editing some core cards, the editor is great, but for custom cards, only yaml mode!
That’s also why I do edits in yaml file and then cut/paste that not the raw editor. Then I can use the GUI editor to see immediately what changing css or spacing looks like before setting that in the yaml and pasting… so it’s the best of both possibilities. I’m not interested in includes but do use comments as well. The dual system works well for me. It’s just a personal preference. The end result is the exact same whichever way you roll.
I think I’m a glutton for punishment. I chose YAML mode since that is what I started with (pre-Lovelace). Doing so has also afforded me a better understanding of how things work under the hood and has forced me to learn more about YAML, CSS, and Javascript, all of which are good to know when something breaks. IMO, there’s nothing more frustrating than having a broken Home Assistant environment and having no idea why.
YAML Mode gets my vote.
Thank you all for your contributions. Keep 'em coming, lots of good info!
Actually, it’s a frequent topic here - have a look.
I personally use Lovelace in GUI mode, but backup its config (.storage folder) and use Add card or something and then copy/paste its config from my text editor.
Shame it doesn’t preserve comments and yes, Raw Editor is hardly useful, mostly for copy/paste as well.
You can always switch to yaml mode, but I came back because of lack of that immediate feedback mentioned by someone earlier.
A general note - there’s so little info on lovelace and people mostly use someone else’s code posted here, it’s often no answer to “why/how it works?” Oh, well…
There is always the official docs for lovelace to start with.
And the demo page allows you to see what and how they work
Well, it’s pretty basic and limited, as I said - almost everything more or less advanced is not documented and people just copy it from each other.
Which leads us to another issue that worries me - custom components.
Apparently these are in most cases the only way to get something beyond basic at the moment.
It’s great, but it looks like frequently things get changed and some mechanisms in HA change so some or all custom components stop working/won’t work anymore.
That requires attention of their creators if they are still available, otherwise you’ll end up with a dead component and need to find an alternative.
That’s why I try to keep the number of custom components to a minimum. But that’s another story…
They provide most of the information for the core cards.
The custom cards are the beauty of Lovelace, people can create cards that make the UI they want.before it wasn’t anywhere near as customisable.
It really depends on how the custom component is created. For instance, the thermostat card (which looks like a Nest thermostat) has been created almost a year ago and it hasn’t been updated for 9 months. It still works perfectly fine.
There are indeed some components that break like the old button card, but since the new button card uses all new implementations of HA it is a lot less likely that this will break any time soon.
But I understand the reluctance to custom components. I have tried to keep it to a minimum, but without them I wouldn’t have been able to create the interface I have now, and unfortunately, I really want them 
I use yaml mode exclusively for all of the reasons mentioned above but also one that was touched on but needs emphasized…
The !include statements not only allow you to use !secrets but also allows you to split up your lovelace configuration into way more manageable bite-sized pieces. For example, this is my lovelace-ui.yaml file (minus a bunch of “resources”):
resources:
## https://github.com/custom-cards/config-template-card
- url: /local/lovelace/config-template-card.js
type: module
## https://github.com/ciotlosm/custom-lovelace/tree/master/group-card
- url: /local/lovelace/group-card.js
type: js
## https://github.com/custom-cards/camera-card
- url: /local/camera-card.js
type: module
## https://github.com/custom-cards/aftership-card
- url: /local/lovelace/aftership-card.js
type: module
## https://github.com/maykar/lovelace-swipe-navigation
- url: /local/lovelace/lovelace-swipe-navigation.js?v=1.0.0
type: js
## https://github.com/gadgetchnnel/lovelace-card-templater
# - url: customcards/lovelace/lovelace-card-templater.js?track=true
# type: js
## https://github.com/kalkih/mini-graph-card
- url: /customcards/lovelace/mini-graph-card-bundle.js?v=0.3.3
type: module
title: Home Assistant
views:
- !include '/config/lovelace_views/lovelace_main_view.yaml'
- !include '/config/lovelace_views/lovelace_media_view.yaml'
- !include '/config/lovelace_views/lovelace_environment_view.yaml'
- !include '/config/lovelace_views/lovelace_automations_view.yaml'
- !include '/config/lovelace_views/lovelace_system_view.yaml'
- !include '/config/lovelace_views/lovelace_zwave_view.yaml'
- !include '/config/lovelace_views/lovelace_security_view.yaml'
Each view gets its own yaml file.
And I’m still trying to figure out the supposed “advantage of instant feedback”. I honestly don’t see the difference between saving the gui/raw editor changes or saving the yaml file changes and hitting the “refresh” button. the “yaml/save/refresh” method is pretty much just as instantaneous as the “gui/save” method, too. Then when you add the extra step of copying and pasting from the raw editor into the yaml for backups/comments I think you pretty much have destroyed any seeming advantage of that possible difference in the perception of “immediate”.
I know some of us have been here before (hi, @DavidFW1960 
) and I’m not trying to start a ruckus but I’m just clarifying that some peoples idea of advantage may not be as much as they imagine.
If it was me, and you are comfortable with yaml (and I’m sure you are) then I would just start with yaml mode and be done with it.
In the GUI you don’t have to save before seeing the change… it does it as you type.
good point.
I might try the yaml mode again 
However, for a new person it can be a bit too much to dive into that straight away and therefore GUI is better to begin with, and then switch to yaml as they feel ready to it.
sometimes with a noticeable delay, sometimes with glitches.
not arguing here, just commenting from my own experience.