Composer is a widely used dependency manager that modern Drupal uses to rely on various third party components. Unfortunately it is not very straightforward to use and was definitely a departure from Drupal 7's self-contained package that had the few dependencies directly shipped. As we realized that Composer itself is a big barrier to make Drupal easier to use, we started to chip away at use cases where Drupal sites would rely on it. I think we now covered the three main use cases, so even though there are parts to improve, the tools are there for each step. I think the combination of these three have the potential to guide users through assembling, maintaining and later extending a Drupal site going forward.
1. Drupal CMS Launcher
The first time someone encounters Composer with Drupal is when they start to set up the website. The Drupal CMS Launcher hides this behind a simple but effective UI. This is the most recent of the three UIs, and is the least developed. That said, when it is done running Composer in the background, it drops you into the Drupal CMS web installer. How you get out of the desktop app to a web host easily is still a question, we don't have simplified solutions for that yet.
2. Project Browser
Drupal CMS has some built-in features to make it easier to get started but you would still want to extend it eventually. That is again where you would need Composer to add new components to the site. Either after installing with the desktop application or some other means on a host, your next tool is Project Browser. This relies on the experimental Package Manager module in core to create a staging copy of your Composer environment and apply any new projects added there. Once that worked, it makes that staging copy live. But this again all happens in the background, hidden behind simple Install buttons.
3. (Automatic) Updates
Finally, you would encounter Composer not only when adding features but keeping existing features up to date. This is where Automatic Updates comes in, which is also built on top of Package Manager the same way Project Browser is. However the use case for Automatic Updates is to find and run Composer (and Drupal) updates for the packages used on the site. This is again done seamlessly behind simple user interface. Despite the name, it does not need to be automatic, it can be set to be initiated by humans only.
In short, we can now help the users best in the scenario where they are with tailored user interfaces. I am looking forward to how we can better guide users between the three areas to make it easier to create, extend and maintain sites. One of the next layers we are building on top is Site Templates to make it easier to get from scratch to a use case specific site. Read Dries Buytaert's blog post about Site Templates and the planned Marketplace for them. Exciting!