There has been much talk, blogging and claims made around the health and longevity of the SharePoint App Model lately. Some have come right out, prognosticating it’s demise and looming death, soon to be part of the boneyard of deprecated features such as SandBox Solutions, Auto-Hosted Apps and the recently announced deprecation of Public Facing Websites. (BTW, Deprecation doesn’t mean dead in it’s tracks immediately, as some often fear. More on that later.)
After having the good fortune of just spending three full days in the belly of the beast at Microsoft HQ in Redmond, I can tell you that any doom and gloom predictions regarding it’s health could not be further from the truth.
These three days did not consist of fluff filled PowerPoint presentations by some Microsoft Newb that was recently introduced to SharePoint and asked to try and evangelize this fairly new and evolving concept called the SharePoint App Model to a group of Microsoft Developers, Partners and Customers.
Quite the contrary, in fact, as the key characters involved in these sessions were none other then Vesa Juvonen, Steve Walker and Jeremy Thake of Microsoft. Any experienced SharePoint Dev can appreciate the extreme value of such a three day experience. If your not entirely familiar, well, let’s just say it’s like being taught to fence by The Three Musketeers.
The sessions were spent reviewing the current state of the App Model, recommendations on using the App Model, the Vision of the App Model and so much more.
While there were many, MANY good topics covered, in an attempt to keep the length of this post within reason, I’m going to highlight my personal favorite “Top 3 Takeaways” from the event. Also keep in mind that most of the details in my takeaways are focused on Office365 and can have some relation to an On-Prem SP, but not necessarily in every case.
Top 3 Takeaways:
(The App Model is not just about App Parts)
As a SharePoint Developer, one of my personal favorite and strongest features to SharePoint is the modularity and ability to reuse Web Parts. When the App Model was first introduced, App Parts immediately became a topic of conversation around the SPDev water cooler. It appeared to have many of the same qualities of the older more matured Web Part cousin, although it still lacked many of the strengths of a full featured Web Part. At it’s best, it’s simply an iframe connected to a page that exists in your SharePoint App, which of course lives in an a separate Site Collection. This no doubt feels rather antiquated and programmatically has a number of challenges associated with it (ex: Responsive Design)
Flash forward to today and many developers still tend to focus (myself included, prior to these three days) on this limitation, casting aside the entire App Model as unreliable or unfit for enterprise level development.
The truth though is that the App Model has become so much more then a simple SharePoint hosted App combined with a few App Parts. An argument could be made that the App Model is not just for SharePoint, but for the entire Suite of Office365 Applications. With new and improved API’s coming out all the time, we are able to connect our SharePoint Applications to other services such as Yammer, OneDrive for Business and more using technologies like JavaScript via the Client Side Object Model (CSOM).
Yes, SharePoint continues to be the primary tool for things like Collaboration Portals, Document Management and Corporate Intranets, but it doesn’t mean that everything that helps populate those entities resides entirely in the scope of a SharePoint Site Collection.
You can be using Yammer for the social integration and then be using a Provider Hosted App to manage your Site Provisioning for a new SharePoint project or team site for example.
If you were like me and had some tunnel vision to the scope of the App Model, I encourage you to take a second look at the depth of the App Model API. Combined with samples provided in the “Office365 Developer Patterns and Practices” website (more info below), you will find alot more to the App Model then simply SharePoint Hosted Apps combined with App Parts. (Hint: Take a look at the “App Script Part”, an example that is simple, but powerful).
2. {Custom Master Pages = Null}
(Do not use custom Master Pages)
In all fairness the above expression is not entirely black and white. As with many things….ok, MOST things in SharePoint, there can be half a dozen ways to accomplish any one thing AND often times the correct answer is subjective to business requirements of the SharePoint Application being built.
- Brought out in one of the sessions is by not using a custom Master Page, Microsoft owns full responsibility on the support of the Master Page. No more can anyone blame your custom Master Page for causing issues. I’ve experienced this on more then one occasion, even when it’s not the fault of the custom Master Page. Spending time proving my custom Master Page’s innocence takes time.
- You automatically receive all the upgrades to the Master Page, without having to keep track of the changes made. You might say, “What if I don’t want the upgrades??” Well, some might be visible upgrades, but some might simply be performance based upgrades that provide no visual change, but greatly enhance performance. (This point I feel is very undervalued, so keep it in mind when weighing your decision)
- These methods allow you to ensure that you have one single point of reference for your CSS and JavaScript files across site collections, even non-publishing based Site Collections. (To me, this was another huge benefit that I think can be under-valued) Highly Branded Team Sites anyone? Need to update a plethora of team sites? No problem!
 |
| Custom Master Page Challenges |
3. {Microsoft != Man Behind The Curtain}
(Microsoft is not telling you to do as they say..with no questions asked!)
Conclusion
Personally, I find that exciting and plan on taking advantage of this new exposure as much as possible. Whose ready to join the ranks and make a difference?
