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!
Man na, the point being that a formatted data language is more tool-friendly and therefore more cost-effective for developing applications and solutions that utilize them. TFS Xaml is not "Xaml" but a consumer (and producer) of it. Xaml is the format/language that makes it work. You cannot build a (cost effective) solution around imperative code, but you can easily around a formatted language.
Also, this is not a discussion/idea around supporting one format over the other. Personally I believe MSFT should innovate this space and make an underlying data format/language much like how IL works in .NET. From this format you can load and save all other formats, particularly the one that works best with tooling and environments found in a given organization and the developers that they employ.
Randy Jackson feels me: https://www.youtube.com/watch?v=nT7500qDa7E
Man na commented
I believe the Visual Studio Team Foundation Server used XAML as a build definition language as of TFS 2013 in favor of a "simpler task- and script-driven cross-platform build system." Now that .NET is cross platform, it shouldn't be much of a barrier anymore, which makes me wonder if "simplicity" and "script-driven" are the real motivation behind abandoning it. Given the fact that build systems are procedural by nature, I would hazard to guess procedural definition is probably a better fit.
Perhaps moreso, I think XAML was foudn to be too crufty and verbose to effectively work with. To set the record, I am not one of those young developers who eschew typed languages in favor of dynamically typed ones for no reason other than to save a few keystrokes. If I had to pick a declarative markup language, JSON appears to be far better choice. In fact, old age wisdom of the 1980's chose the .res or resw formats to describe application resources well before XML, since it's syntax is quite similar to JSON.
Defining and editing a few objects in XML can easily turn into pages of confusing and hard to follow labyrynth of text despite intellisense, color coded tags and automatic indentation facilities. It inherently suffers from the same thing that makes HTML difficult to edit and follow. Consquently, a graphical editors usually become insufficient or limiting, requiring frequent round trips between the graphical and text editors. Even after several decades of HTML, most of its development is still done using the primitive text editor. In contrast, PostScript, an older and almost as widely used language suffers from a shortage of programmers because the language can be so easily generated and rendered that it makes hand coding it tantamount to programming in assembly language with little to no benefit.
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).