One thing I don’t like is when you setup an integration only to find out the configuration has failed even if you followed the documented configuration and have to restart Home Assistant 3 more times to get it working right.
It makes my zwave network very unhappy. So I welcome anything that causes me to have to restart Home Assistant.
So you have this nice thing.
You want to grow this nice thing because if you don’t it tends to stagnate and die.
Understandable.
Pissing off a large section of your loyal user-base to grow the nice thing?
Unfortunately that has to be done sometimes simply due to practicalities.
You have to be very careful about choosing your new target demographic though. For example:
By dumbing down the nice thing you are going to attract a lot more dummies. And the situation shown in that comic is going to become more common, not less.
Ask yourself, do you really want Home Assistant to be used by people who would have trouble setting a clock on a microwave oven?
This is all a bit rambling and I do have to admit that so far the shift away from YAML has not affected me adversely. I can only remember one or two occasions where I had to delve into the undocumented .storage black box to fix things that were not fixable via the UI. That was in the early days though and I have not had to do this lately. I do actually like discovery and the way my commercial and DIY devices seamlessly integrate into Home Assistant.
One thing that has become slightly more difficult is community support. Rather than asking for correctly formatted configuration code so it can be easily cut/pasted/corrected I find I have to post more screenshots edited to show a button press procedure. This is time consuming and tedious but I’m not forced to do it. So I may just end up doing less.
Also I learned YAML and it was surprisingly easy. So new users should have to learn it as well. Now get the hell off my lawn. ~ 
Wanders away yelling at clouds ~ /jk
But seriously, I find it more efficient to define automations and scripts in YAML and JINJA than the UI and if the current ADR ever changes to exclude that I would have to re-evaluate my use of Home Assistant. It is good to hear there are currently no plans to remove this.
Same even though I use Lovelace in Storage mode and I maintain lovelace in yaml and use cut/paste so I kinda get the best of both methods. I have pretty much switched to everything via GUI except scripts/automations and when GUI adds new support for integrations I switch to use them. I don’t see a good reason not to use the GUI where possible for that kind of stuff.
I forgot about the the front end. Yes this is the best of both worlds.
I have an example of needing to do this…
A few weeks ago after an update/restart my frontend wouldn’t load (of course I did a config check first just like every other time!) and I started getting errors in my log about the HACS component (along with a lot of other related/unrelated things). And of course we all know that the first recommended troubleshooting step is to remove the offending custom component (it says so right there in the first lines of the log).
The problem was that I had HACS configured via the UI at some point and because I didn’t have access to the front end I couldn’t remove it via the UI. I was then pretty much stuck. It literally took several hours of troubleshooting/editing the .storage files to purge them of anything HACS related/etc. until it was all back up and running again. I even eventually had to create an entirely different virgin HA docker container and added things back a bit at a time from my original config until I “found” the issue.
So…without being able to edit those mostly not-easily-readable JSON files and then knowing how things were supposed to work in the first place because I usually configure (mostly…) everything in yaml I would have ended up needing to completely restart my main config from scratch. And even with my experience with things HA related I was still unsure about where all the bits of the HACS integration were spread out in the .storage files.
I still don’t know why things got broken like they did but I’m fairly confident in saying that if I was one of the newly-targeted “non-tech savvy” users I would have been completely lost on how to proceed to fix things. And having everything configured in the “black-box” of the hidden .storage files only adds to that.
And since there is no “customer service” that the non-tech savvy user can reach out to for help they will come here. Then we are supposed to try to help them fix their broken systems by telling them…what exactly? To use SSH/SAMBA (which they probably don’t know how to use and haven’t ever got it set up) and go into their .storage files and edit those un-editable files that are written in unreadable JSON and to delete every reference to some UI configured integration that might be spread across several files? But "oh, yeah…make sure you don’t mess up the syntax of those mysterious files because if you do all hope is lost for ever fixing it without starting completely from scratch. But, hey, no pressure. “Wait, you didn’t make a backup?” Of course not. And why would they since the new target user is not tech savvy…
TBH, that’s kind of where I’m headed right now.
EDIT:
It would be interesting to see where HA would end up if all of the “power users” stopped interacting on the forums trying to help out all of the new target “non-tech savvy” users when things break and they weren’t here to hold the new users hands thru fixing it.
absolutely
I much prefer using YAML for as many things as possible being that is how I learnt how to use HA. I find it simple now, and mostly easy to troubleshoot.
I can see how for new users having an idiot-proof setup via integration makes life easy getting things to work…until it doesn’t.
Well, I try to get as much of them out of yaml. It sometimes needs some json crafting to create discovery messages, but it is doable.
My 2 cents: sure, it’s not my preferred solution. But I want my family to use HA as well and they can absolutely not be trusted with YAML files. I want HA to grow, I accept the devs decision and I’ll make the integration that I help maintain ready for UI.
(edit: must have pressed the wrong button, this was not meant as a reply to @kanga_who)
Is it the time for a new fork?
There have been more and more changes recently that do not sit well with current users.
Do I smell something similar to emby/jellyfin?
Hopefully not. We’re mostly users, not developers.
So don’t give them access. Pretty simple. I don’t trust my wife with any admin functions, hence why her account is a user account.
I’m sorry all the cobol programmers are busy fixing the US unemployment systems for the foreseeable future.
Yeah but IBM are doing lessons to bring the workforce up to speed.
I mean, I want them to use it in their place, I don’t live with them 
. Biggest threat is that they’ll move to some closed solution.
You don’t have to chuck comments all over the place though. Where you used to put your integration config, you’d simply replace it with something like this (most likely saving lines in fact):
# Set up this integration via Configuration -> Integrations
# Enable the following options: HTML Parser, X, Y, Z
I think this approach is much simpler overall - clear instructions for users browsing your repo, no confusion over secrets.yaml stuff, no possibility of breaking their config by improperly pasting YAML, no missed options, no need to restart afterwards, no breaking changes during upgrades since the config gets migrated, etc.
If you can accept needing to do things a slightly different way, I think this change is beneficial for the most part.
I see the reasoning in moving to a more UI-oriented configuration; but having everything tidy and machine-readible in one configuration file was for me always a key feature of Home Assistant. (I’m not saying I haven’t browsed this board hour-long to find the right combination of single-double-quotes to make the config work…)
Isn’t the obvious solution to keep both – that is, UI-based configuration and YAML-based configuration – and make a two-way converter as part of Home Assistant core? That would keep the good and proven flexibility and sharability of YAML but would enable Home Assistant to a broader audience. It would also lift the burden from integration developers; they simply integrate abstract read_config methods which deliver data defined either via UI oder YAML.
I would classify myself as a user (definitely not a developer) and am in two minds about that idea @Thewho
The present focus seems to be on building a low level user friendly environment.
It’s clear to me that comes at the expense of people who want a machine that is totally user friendly to those who want to dig in and learn stuff to make a personalised environment.
Is there even a roadmap for a stable version 1 at the moment?
When is it planned for? 0.150.xx? or much later?
Why not officially fork it now?
What if you forked it prior to the commencement of the UI and progress that to focus on a stable version 1 for those who want to delve in deeply with all the freedom of YAML config.
While on the other fork you can then continue to make your fancy UI to better interest your target group?
It would be very interesting to see which fork becomes the most downloaded, very interesting!
PS: To Be Clear…If something along these lines were to happen I would like this to be an official fork as I am a Nabu Casa subscriber and I want to continue with that fantastic service.