Is the Tide Turning on project.json?
I am not exactly a fan of the new project.json initiative underway between the Visual Studio and ASP.NET Core rewrite. In fact, I have been so concerned with it that I have created a vote to change this very issue along with other latent misgivings in the Visual Studio project system.
The JSON specification simply does not support comments within its documents, a fact (read: oversight) that seems to have escaped the ASP.NET Core team in their analysis of JSON the format of choice to serialize their new project initiative.
Recently someone posted a very sane and reality-based Tweet stating that JSON files should NOT be used for configuration, schemas, etc. Hallelujah! I am not some mad man wandering alone in this wilderness after all.
In response to that tweet, other MSFT developers have jumped in and have tried to defend the questionable — and inexplicable from the Microsoft IP perspective, as I explain in a bit — decision to pursue JSON over other formats. In fact, a good number of developers (as you can see from the vote I am promoting here) prefer other formats such as XML, the mature serialization technology to represent their data.
Now, there are many data formats out there, and that is something that should definitely be accounted for in future versions of tooling. However, none of these formats are as powerful and native to Microsoft developers as Xaml.
Yes, Xaml. A Microsoft-created, supported, and mature _serialization and object-description_ language used in basically every major Microsoft group with the exception of … well, ASP.NET and .NET Core. To start with here, Xaml stands for eXtensible Application Markup Language. Why, from the sounds of it, defining a new project structure is perfect for this! In fact, you can define an entire application in Xaml if you are so inclined (see: the A in Xaml). Xaml can be used to describe any _POCO_ you wish, not just user interface elements.
As any example, you can see this screenshot of the Console Application — yes, a _Console Application described in Xaml_ — that is used here at Developer Wins! to build the weekly vote reports deployed every Friday morning:
It is a small jump from here to see that Xaml can be used to support a new project structure altogether (and the effort would be minimal, considering the vast resources that have been placed in the new project.json structure already). Again, the tooling is already in place and is mature.
To summarize, Xaml is:
- An eXtensible Application Markup Language (bears repeating)
- Class-driven schema model (no need to create “yet another artifact” to describe the item you are describing — the class that you have already created _is_ the schema.)
- Extremely powerful serialization model
- A Microsoft property and invention
- Mature (nearly a decade old)
Value IP (Intellectual Property)
Much like how the Windows Platform group is harming the value of its owns developers by building a backwards bridge from iOS into Windows, the ASP.NET Core group is ultimately harming Microsoft’s IP portfolio by choosing another external document format standard over one that already works within its technological capabilities. Don’t get me wrong (too late, I know, haha!), I am all for adopting open standards, and the ASP.NET group — along with the Edge group — have done a remarkable job in doing just that. However, in this case, this certainly requires some additional review and consideration, especially when the way that they are utilizing a document format is violating the very standards they are trying to uphold.
Scheduling and Effort
Finally, the last consideration here is scheduling and effort. Look at all the effort being placed into this new project system and the serious overlap of existing functionality with existing MSBuild and *proj files. Look at all the effort put into the new tooling for intellisense and schema. If Xaml was leveraged instead, minimal effort would have been put into update the tooling to play with the new bits (this is talking from the Visual Studio IDE and not Visual Studio Code perspective), and we would probably get less blog posts about how schedules are slipping.
Show Your Support
If you agree with me and would like to see Microsoft reconsider its current path in its project.json initiative, please show your support here: