By now. we all are familiar with the justifications for the new SharePoint App Model. Chris Johnson recently wrote a nice piece on the history of the Sandbox Solution model, and why he sees the App Model as the better way to isolate code moving forward. Talk to anyone in the product group or any of the SharePoint field engineers or support professionals in Microsoft, and they’ll tell you that custom code in SharePoint has been the number one cause of upgrade problems, support incidents, and performance issues. Speaking to the general disdain for shoddy SharePoint consultants and their poorly tested customizations, I’ve even heard on more than one occasion from people at Microsoft the off-the-cuff remark:
Get your BLEEPING code out of my SharePoint.
I get the feelings here. It’s a quality issue. Microsoft can’t guarantee the quality of their platform as long as other people can introduce arbitrary code into their system.
Regarding quality though, if I delivered a custom-built web application to a customer and the markup looked like some of the things I find in SharePoint, I’d get called to the carpet.
After some recent updates to SharePoint Online that have wreaked havoc on our SharePoint branding customizations, I’m going to have to call a duck a duck. No, I’m not talking about Peyton Manning’s wobbling throws (#GoHawks!), I’m talking about the quality (or lack thereof) of the html, markup, and front-end code of SharePoint. If Microsoft so badly wants to get my code out of their platform, I’m going to say that I equally would like them to get their UI out of my SharePoint. Just give me the data, and I’ll make the UI, thank-you-very-much. Complete separation of church and state, and presentation and data is what I want.
In this post I’ll take a look at some of the eggs laid and why I feel Microsoft should get out of the business of writing markup, and focus on the data instead.
