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.

Motivation for Writing This

After working on the branding for our intranet, a recent unannounced change to Office365 SharePoint Online markup caused us to scramble to fix our branding efforts. Here is the older markup from one of our development tenants, for the “Sites” link in the SuiteBar:

As is typically done in SharePoint branding projects, we had CSS targeting these various class names to style them. Then one day, the markup changed to this:

As you can see, the whole structure of the markup changed, including the class names and prefixes. This is on the heels of Microsoft changing the title attribute for list required fields, that many developers have been leveraging for some time.

It’s clear by these changes that Microsoft does not want us in their markup, enhancing or building upon their UI. They want us to write client app parts or full screen experiences, and leave the SharePoint UI alone. But if that’s the case, let’s take a look at some examples of a Microsoft-generated UI, and I think you’ll agree that the SharePoint development community could do a lot better.

Standards and Semantics, Anyone?

While most of the web development world has been working for years to deliver high-quality, standards-compliant and semantic markup, a look through the SharePoint product shows this wasn’t a priority for them. You’ll find numerous instances of non-standard html tags or attributes. Yes, looking at you <ie:menu>:

Semantic and clean javascript menus based on list items or definitions (<li>, <dd>) have been around for almost a decade, and we are still seeing these examples in the product.

How about standard HTML attributes? Knockout.js has been around since 2010, and a prime example of using the HTML5 data- attributes as extensibility points. But we still see Microsoft using its own ad-hoc attributes:

Reinventing the Wheel / Working in a Vacuum

Modular javascript loading patterns have been discussed since CommonJS started in 2009. However we still have a roll-your-own implementation of async loading:

Yuck.

Ever tried to use a library like Require.js with SharePoint to take advantage of modular loading, CDNs, and local fallbacks? Good luck getting that to play with SharePoint scripts and avoiding race conditions. Chain your jquery(document.ready) to your SP.SOD.ExecuteFunc() to your CSOM executeQueryAsync callback with your shim config, and your head will explode.

How about font icons? Pretty standard way to make icons that can be styled exclusively via CSS. Perfect for use in a theming mechanism. In SharePoint? Another roll-your-own implementation that dynamically creates images on the server side:

It hurts to think about the development effort spent to create a mechanism to generate dynamic images based on colors specified in a SharePoint theme, while major pieces like responsive design have gone completely untouched in the product.

How about the abomination that is the Minimal Download Strategy? This is the first thing I turn off when developing a SharePoint branding solution. Problems with caching, urls, browser location history, and OOB functionality. The MDS just does not play well with other commonly used frameworks and implementations. Haven’t other examples of writing Single Page Applications been around to model after?

While we’ve all been working with jQuery as a defacto standard library for years, we still can’t use the $ prefix for jQuery code in our SharePoint solutions. How about leveraging the typical DOM ready approach ($( document ).ready(function() {});)? Nope, SharePoint has this thing called _spBodyOnLoadFunctionNames instead:

Quality Code

Plenty of examples exist where just plain poor development practices are used. Polluting the global javascript namespace, overriding native javascript object prototypes, code bloat. Take this markup for the Focus on Content button:

A number of things stand out with this. Inline CSS styles, inline javascript event handlers. If I delivered javascript code to a client that looked like this.firstChild.firstChild.firstChild.style.top, I’d get skewered during a code review. Besides the code quality issues here there are the larger UX implications of even having this button on the suite bar to begin with. Has anyone actually used the Focus On Content button? I would love to know how much effort went into building that piece, as it has presented very little value to any of our customers. And is there any easy way to turn it off? Of course not.

Summary

When I look at great platforms like WordPress, with a thriving ecosystem of Themes and Plugins that can completely change the look and feel, and with developer hooks for virtually every piece of functionality, I wonder when, if ever, SharePoint will get to a similar level of maturity in its separation of presentation and data. And you certainly don’t hear WordPress telling it’s developers to “get your PHP out of our platform”. Quite the contrary.