Innovate the Xaml Designer, Dawg
This is in regards to the following link and comment:
The high level goal here is to reduce the amount of time and therefore cost in developing highly functional and reliable applications. The primary value in Xaml is that, unlike code and imperative instructions, it is easily parsed by a designer and tooling. Additionally, it lowers the barrier to entry so that a greater number of resources within an organization can utilize and work with it during the lifetime of an application.
The ask here is simple: please start thinking of Xaml as an *application*-definition language, rather than one for the UI. By thinking of Xaml as a way of describing regular ol' POCO's, a true opportunity arises to reduce cost throughout the lifetime of an application.
The original Xaml designer for WPF understood this. You could load up any POCO described in Xaml and it would allow you to edit its properties in the Properties window. In fact I go into a little bit of detail of this here:
One of the great many promises of the WPF/Xaml workflow was tighter integration and collaboration between designer and developer. This of course should remain as a goal, but this ask would encourage the Tooling group to think bigger, and to extend the tooling power to beyond design and development, and into other areas such as DevOps.
As I mention in the comment, a great deal of power could be had by providing a deliverable to DevOps that is the "configuration" for the application, but given in a visually appealing and sensible way. DevOps would then modify and configure applications in a visual way rather than one that is error-prone and at times, can be extremely expensive. A great example of this can be found here:
If a visually-driven configuration was used for this instead, this sort of costly mistake (and many many more) could be avoided.
Anyways, off of my soapbox for now. Thank you for any consideration towards this ideal!
Dominic Pease commented
I'd like to add that even the XAML editor (rather than visual design tools) needs improvement. In practice, using the editor with non-UI root elements, or creating extensive and complex graphs of the same, causes lots of weird little bugs to show up: types or properties of types not found, namespaces not recognized, Intellisense being generally unhelpful.
I could live without the visual stuff (property grids and so forth) as long as we could get full editing support (preferably including recognition of things like custom markup extensions, too).