If you’ve worked with SharePoint in the past few years, you may be under the impression that custom SharePoint development is frustrating. Traditionally, client-side development in SharePoint has been somewhat limited from a developer perspective. There are several methods for customizing SharePoint—we will refer to them as the “Good, Better, and Best” methods. The “Good” and “Better” methods involve using the native (out-of-the-box) SharePoint features including the content editor web part and document libraries. The “Best” method is using the SharePoint Framework to build, package, deploy, scale, and configure a client-side SharePoint Web App. Let’s take a closer look at each of these methods.
The Good Method
This method, aka the “copy/paste” method, involves writing HTML and dropping it directly into the content editor web part and creating custom master pages that link to CSS and JavaScript files.
Pros:
Most SharePoint power users are accustomed to this technique.
It’s very easy to change the content on a page (this is also a drawback!).
If all you’re doing is creating content (not building web apps) this isn’t a bad way to go.
Cons:
There is no centralized location for the code on the site.
The edit source HTML modal window is clumsy and closer to Notepad than an integrated development environment.
SharePoint will often change the code when opening/saving the source HTML.
Copy/paste can be error prone and create mysterious issues.
The Better Method
In this method, we build our project with Sass, TypeScript, and other JavaScript Frameworks. Using Gulp to generate the compiled assets, we ship them to a SharePoint document library. Instead of copying/pasting HTML into the content editor web part, we simply point the web part to our stored HTML file in the document library.
Pros:
Falls in line with normal web application development methodologies.
Takes advantage of common project structure that is mimicked in the assets document library.
Files in the document library can be version controlled and easier to revert.
Less likely to be affected by unexpected SharePoint code manipulation.
Easily deployed/updated by changing assets in the centralized document library.
Cons:
Harder for power users to make content changes within the page they want to update.
Requires more assets and files to be managed within SharePoint.
Disconnected source control awareness if files are manually changed outside of a development cycle.
Less distributable across multiple sites.
The Best Method
The best approach is to use SharePoint Framework to build, package, deploy, scale, and configure a client-side web application.
What Is SharePoint Framework?
The SharePoint Framework (SPFx) is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data, and support for open source tooling. SPFx uses modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile ready.
Why SharePoint Framework?
In the past, we developed web parts as full trust C# assemblies that we installed on the cloud or servers. Current development models, however, involve JavaScript running in a browser and making REST API calls to both SharePoint and Office 365 back-end workloads. C# assemblies don’t work in this world—we needed a new development model. SPFx is the next evolution in SharePoint development that helps bring the modern web to the enterprise. In fact, SharePoint has been using SPFx to build your favorite web parts (document library, lists, calendars, etc.) for years!
How Does SharePoint Framework Work?
Microsoft has provided a structured template to build SPFx web applications using Yeoman recipes. When creating a SPFx project, you can choose from a variety of base front-end frameworks including Knockout.js, React.js, Angular.js, and more to come. Included in the starter kit, you get pre-defined Gulp tasks and SharePoint plumbing to immediately begin writing code for your application and get it deployed. SPFx templates leverage TypeScript and Webkit as utility frameworks for development that bring more best practices to your solution. The output of a production build (using Gulp) is a SharePoint package file that can be deployed as an app to your company’s App Catalog. From there, it can be installed and used in any site collection. When updates are made to the app, everyone using the app will get the latest and greatest code automatically. The apps are added to pages in the same way that other web parts are. You can optionally include custom configuration for your app to personalize the experience and functionality for each instance of the app.
What Does SharePoint Framework Mean for Our Clients?
Stability:
Much more control over building distributed client-side apps.
Breaks down walls between modern web development and SharePoint.
Best practice SharePoint integration and communication.
Microsoft’s recommended approach to building client-side apps.
Maintainability:
Faster development (time = money).
Better maintainability.
Controlled and obfuscated SharePoint integration.
Scalability:
Once web apps are deployed to the App Catalog, end users can easily use the apps in their sites and configure each web part separately.
Development teams can deploy once and don’t need to be involved in the downstream usage in other sites.
Helpful Links and Resources:
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
