Sergey Nivens - Fotolia
At the Microsoft Ignite conference earlier this year, one of the most intriguing announcements was its new SharePoint Framework (SPFx): a significant overhaul of a now-classic platform, beefed up not only for the cloud, but for new ways of thinking in the enterprise.
Over its past few releases, new SharePoint features have centered on increased utility, expanded search capabilities and increased integration. More than a features update, the recent changes to SharePoint and the emergence of SharePoint Framework (SPFx) signal a new creature entirely that addresses the changing landscape of business processes, functionality and app requirements.
Here's a rundown of the new capabilities enabled by SharePoint Framework.
Cloud-friendly, mobile-friendly is now the default
The biggest architectural shift in SharePoint is an outright reversal of its lifelong structure: always a server-side technology, the new SharePoint Framework is now based on a client-side model.
Why does this matter? First, putting the development emphasis on the receiving end of a SharePoint Online process is Microsoft's biggest step ever toward mobile-first SharePoint. Where its previous multichannel strategies focused on HTML5 modification, developing apps from the client side is more than an adaptation to accommodate mobile devices; it's a ground-up rethinking of what SharePoint can be for the enterprise, taking content and collaborative processes into the field as a default.
This important architectural change brings SharePoint-based applications onto equal footing with Office 365 companion applications: the traditional Word, Excel, PowerPoint family of products that has lived comfortably on tablets and cellphones for the past couple of years. The SharePoint-based apps will not only match their peer apps in look and feel, but in depth of functionality -- and then some.
Development and maintenance are now less expensive
Because the SPFx model is client-side, it is platform-agnostic. As a result, .NET knowledge isn't requisite.
Are .NET developers obsolete, then? One of the great consequences of SharePoint and similar point-and-click application platforms is the overhead required to enable their one-stop-shopping approach. On average, a typical SharePoint site will consume about 40% more resources than a from-scratch .NET site with identical functionality. The trade-off, of course, is the extra memory and storage for the time saved deploying the site.
That's an easier trade-off today than it was previously, thanks to the decreasing cost of computing power. But, sometimes, the efficiency of a site, or of an application within a site, truly makes a difference; sometimes it is the game-changing edge over the competition. A .NET developer's work will be cleaner, more efficient and more flexible than an app built from a menu. Put simply, the .NET developer isn't going the way of the dodo anytime soon.
Ignite also unveiled SPFx-specific updates to its Patterns & Practices, including application design patterns, SPFx coding samples, reusable components and best practices. These resources can greatly accelerate the process of adopting SPFx.
SPFx plays well with others
Since Microsoft Office SharePoint Server 2007, SharePoint has been architecturally integrated with the Microsoft Office product suite, and even more so as SharePoint Online, a component of the cloud-based Office 365. Mixing and matching Office components -- Excel, PowerPoint, Power BI, etc. -- in custom SharePoint apps and processes has gotten easier with time, and those components are now openly interactive within SharePoint pages.
Per the Ignite presentations of SPFx, the product isn't yet production-ready, but is just around the corner. It promises to breathe new life into a tried and true platform.
How Office 365 and SharePoint fit into the Microsoft roadmap
Where is Office 365 headed?
Best practices for Office 365 management and Active Directory