SharePoint Framework Development

Published: May 20, 2020


Microsoft SharePoint is progressively continuing its odyssey after its first launch in 2001 as an on-premises product. The progress is made in various versions of the SharePoint:


SharePoint 2001 → SharePoint 2003 → SharePoint 2007 → SharePoint 2010 → SharePoint 2013 → SharePoint 2016 → SharePoint 2019


Office 365 (with SharePoint 2010 interface) → Office 365 (with SharePoint 2013 interface) → Office 365 Groups with SharePoint Online sites → Microsoft Teams with SharePoint Online sites

With each version, the Microsoft has provided various new features and also provided the different ways to achieve customized requirements of an end-user. For customization, the Microsoft is provisioning the SharePoint Development Platform. For developing the add-ins, client-side components and solutions having different scopes which are addressing a wide necessities scope.

To customize our requirement in the modern user interface of Office 365, the Microsoft has introduced the SharePoint Framework (SPFx). For On-premise (SharePoint 2016 Feature Pack 2 and SharePoint 2019) and SharePoint Online both, the SharePoint Framework is suitable.

A page and web part model, the SharePoint Framework (SPFx), gives full assistance for the easy integration with SharePoint, support for open source tooling and the client-side SharePoint development. One can utilize the modern web technologies and tools in his/her development environment with the SharePoint Framework to assemble the productive experiences and applications which are portable prepared and responsive from the very beginning.

Table of Content

  1. SharePoint Framework’s Key Features
  2. Why to use the SharePoint Framework?
  3. Tools & Libraries
  4. Pros & Cons of the SharePoint Framework
  5. Challenges in SharePoint Framework Development
  6. Customization with the SharePoint Framework
  7. SharePoint Framework Development Environment Set-up
  8. Conclusion

SharePoint Framework’s Key Features

Below listed features are its key features:

  • It runs inthe current-user context and connection in the browser.
  • No iFramescustomization which conveys that JavaScript is directly embedded inthe page.
  • Its controls are rendered in the normal page DOM, and are responsive and accessible by nature.
  • Itslifecycle is easily accessible with render, load, serialize,deserialize and more.
  • Being a framework-agnostic, it can be used with any JavaScriptframework – React, Knockout, Angular, and more.
  • Its performance is reliable.
  • The SPFx client-side solutions, which are approved by the tenant administrators or delegates, can be used by one on all sites including “Team Site”, “Communication Site”,“Group/Personal Sites”, etc.
  • The client development tools which are available as an open source such as npm, TypeScript, Yeoman, etc. can be used by an end-user for the development purpose.
  • The web-parts developed using the SPFx can be consumed in both the classic and modern page.

Why to use the SharePoint Framework?

For performing any functionality in the On-premise enterprise environment, Microsoft introduced many different approaches like its own OOTB, custom web-parts, SharePoint feature XML, Event Receivers, etc. There are available features coded in C#, complied in DLLs and finally deployed to on-premises farms. This approach is suitable up to single enterprise environment but fails when it comes to multiple tenants running side by side. To overcome with this, two approaches were bring in front to use in the SharePoint Online and they are mentioned below:

  1. Client-side JavaScript Injection
    • In the SharePoint Online, the most commonly used web parts is ‘Script Editor’ and it is powerful in its own way.
    • It is simple and effective as one can paste the JavaScript in it and this JS executes on the page render event.
    • It can easily interact with the other controls of the page as it runs in the same browser page context and also in the same DOM.
    • Well, it has its own drawbacks also. The configuration options can’t be easily provide in it. If an end-user modify the script by editing the page then it might lead to break the web-part functionality.
    • Also this web-part is not known for “Safe for Scripting”.
    • “NoScript” feature is enabled on the most of site collections, which provision self-service, like Team Sites, Group Sites and My-Sites. This indicates that the Script Editor web-part is blocked from execution on these sites with the removal of the Add/Customize Pages (ACP) permission in SharePoint.
  2. SharePoint Add-ins
    • The Add-in model is the option available for solutions to be executed in the NoScript sites.
    • This option renders an iFrame in which the actual functionalities reside and execute.
    • It is purely an external to the system and don’t have accessibility on the DOM/connection. Thus, it is easily trustable and deployable, and one can consume them in the NoScript sites.
    • Now they also have their own consequences due to running in an iFrame. As iFrame requires to make a request to totally new page which goes through the authentication and authorization, so it is comparatively slower than the Script Editor web-part.
    • The iFrame is having a stronger security as the controls loaded inside it can’t be accessible through the other controls of the page and the loaded controls have no access to their connection to Office 365.
    • It hurdles in the way of responsiveness, inheritance of CSS and theming.

To overcome these hurdles, Microsoft has announced the SharePoint Framework Development model for the client-side development. The current development model includes the JavaScript execution in a browser through REST API calls to SharePoint and O365 back-end workloads.

Tools & Libraries

Different client-side JavaScript libraries are incorporated in the SharePoint Framework Development. Let’s discuss on the tools & libraries which are useful in the development of a client-side web-part.

Tools Libraries
  1. TypeScript
    • A JavaScript typed superset which complies in to a plain JavaScript is called as “TypeScript”.
    • The TypeScript classes, modules and interfaces are used in the client-side development tools of the SharePoint. These tools are used to build a robust client-side web-parts.
    • Refer this link to know more about it.
  2. JavaScript frameworks
    • Number of JavaScript frameworks are available to build a client-side web-parts.
    • In a SharePoint page, a client-side web-part is dropped as a component. Thus, it requires to choose a JavaScript framework which supports the component model.
    • Below are some popular frameworks are listed:
  3. Node Package Manager (npm)
    • Alike to the NuGet in .NET, Node Package Manager (npm) is used to manage the dependencies and the required JavaScript helpers in the SharePoint client-side development tools.
    • Mainly, npm is the built-in of the Node.js setup.
  4. Node.js
    • The Node.js is an open source and cross-platform runtime environment which is utilized for the hosting and serving any JavaScript code.
    • Its ecosystem is tightly bound with npm and task runners like gulp for provisioning an effective environment for the JavaScript based applications.
    • Like IIS Express or IIS, it includes some tools for simplifying the client-side development.
    • To learn more about it, refer this link.
  5. Gulp task runner
    • In the SharePoint client-side development, it is employed as the build process task runner to carry out the below process:
      • Bundling and minifying the CSS and JavaScript files
      • Prior to each build, execution of the tools required in the bundling and minification tasks
      • Compilation of the LESS or Sass files to CSS
      • Compilation of the TypeScript files into JavaScript
    • One can start to know about it from basics using this link.
  6. Webpack
    • It is a module bundler. It collects the web-part files and dependencies to generate one or more JavaScript bundles.
    • The bundling is carried out to define the modules and their usage location. For bundling, the CommonJS is used by the development tool chain.
    • Using the universal module loader SystemJS, the modules are loaded to bind the scope of the web-part for its execution in its own namespace.
    • To have more knowledge about it, refer this link.
  7. Yeoman generators
    • The Yeoman allows to stay productive with the initiation of a new project as per the best practices and tools.
    • To commence a new client-side web part project, the Yeoman SharePoint generator is there as a part of the framework itself.
    • Learn about it using this link.
    • Refer this link to know about the scaffolding a web app with Yeoman.
  8. Source code editors
    • One can use any HTML/JavaScript code editors as per his choice as the SharePoint Framework is client-side driven development. Below are the some of the listed code editor:
    • Visual Studio Code is used in the documents and examples of the Microsoft SharePoint Framework documentation. It is a powerful source code editor from Microsoft in addition of being a lightweight. It provides the default built-in support for the TypeScript, Node.js and JavaScript.
  9. SharePoint REST APIs
    • To make the utmost usage of the client-side webpart, the SharePoint Framework enables us to communicate with the SharePoint and different workloads via SharePoint REST APIs.
    • Refer this link for carrying out any action using REST call on the SharePoint List.
  10. Patterns and Practices

Pros & Cons of the SharePoint Framework

Like every story has its two sides, the SharePoint Framework has its two sides in terms of its usage – Pros and Cons.


  • It runs in the user context so only the allowable data content will be displayed to an end-user.
  • It is light-weight, fast and responsive as SPFx is completely a client side and uses NodeJS. It is compatible with the Office Fabric UI components and becomes responsive.
  • When the server-side solutions are not used wisely, they might cause a damage from a site collection to an entire SharePoint farm. One can mitigate this risk using the client-side development which is supported by the SPFx.
  • If one’s online tenant is either running on the old SharePoint 2013 classic mode or upgraded to latest tenant feature, then one can have a back seat and relaxed as the SPFx is compatible with both the modern as well as classic pages.
  • In the erstwhile client-side code, one is required to use some extra variables and make some calls for fetching the configurations. Now,this becomes very convenient to use with the SPFx as one can assign the properties of a custom client-side web-parts and configure it accordingly.
  • The SPFx provisions its own deployment mechanism which includes the app bundling, the app packaging, the app shipping to store (or to local SharePoint App Catalog) and deployment in the tenant with the proper permission. The whole process is managed in better way for the client-side web parts.
  • If one is not having internet connection, then also one can develop on the SPFx coming with a local workbench which is effective in developing and testing of a client-side web-parts.
  • It is scalable as not being limited to SharePoint. One can use NodeJS and other component available in NodeJS community in the SPFx client-side development. A client-side web part can be made to interact with Office365, Azure, One Drive, Outlook, etc. with the Microsoft Graph API development.
  • No specific machine related requirement is necessary for the development. One can use any machine-like Windows, Mac or Linux for the client-side development. The only necessity is to set-up the development environment through NodeJS, Gulp and Yeoman template installation of the framework. To develop SPFx web-parts, one is simply required having any text editor.
  • The business logic or code of a client-side web-part is secured as it can’t be accessed from the page source or browser inspect.


  • For the classic developers of the SharePoint, it is completely a new sack of development environment. They are required to start from NodeJS → Typescript → Webpacks → Gulp.
  • Being at client-side, critical business requirement must not be fulfilled using the SPFx. By doing reverse engineering on the client-side web-parts, one can easily extract the business logic as it is JavaScript only at the end.

Challenges in SharePoint Framework Development

  • From C# to JavaScript
    • For a normal SharePoint developer, they are required to shift from the C# side to JavaScript and make use of the different development tools apart from the Visual Studio.
    • Thus, they found difficulties in adapting the SPFx at the initial stage.
  • Chrome’s Dev certificate issue
    • After the executing the gulp trust-dev-cert command, challenges related to the developer certificate will be faced while using the Chrome as a development browser.
    • For the certificate validation, Chrome has changed its model starting from v58. When accessing the local workbench, “Your connection is not private” warning will be displayed.
    • Microsoft has updated logic for the certification creation in the @microsoft/gulp-core-build-serve.
    • In the current solution, remove this folder and execute the npm install command to have the updated package. One is also required to execute the below commands in the sequential form to resolve the issue related to the certification creation logic.
      1. untrust-dev-cert
      2. trust-dev-cert

Customization with the SharePoint Framework

Development Approaches

This modern framework provides two development approaches for customization in the classic/modern sites:

  1. SPFx Web Parts
  2. SPFx Extension
  1. SPFx Web Parts
    • The controls showing up inside a SharePoint page however running in the browser locally are the SharePoint Framework client-side web-parts.
    • With the usage of the modern script development tools and the SharePoint workbench which is the development surface, a client-side web parts are built and can be deployed to any modern page or classic web part page in the Office365 tenant.
    • A client-side web part can also be built with the common scripting frameworks like React, AngularJS, Knockout, etc.
    • For example: One can easily create the experience alike to the same components used in Office365 with the use of React along with Office UI Fabric React components.
  2. SPFx Extensions
    • Using the similar SharePoint Framework tools and libraries, the SPFx Extensions allow us to extend the SharePoint end-user experience into modern pages and document libraries.
    • Using the similar SharePoint Framework tools and libraries, the SPFx Extensions allow us to extend the SharePoint end-user experience into modern pages and document libraries.
      1. Application Customizers
        • The application customizers are the Content and Script editors of the modern sites.
        • It includes the scripts into a page, gets to the popular HTML element placeholders and extends them with the custom renderings.
      2. Field Customizers
        • It allows us to modify the existing data views of the fields of the list.
      3. Command Sets
        • It allows to extend and add the new action buttons in the SharePoint command surfaces and provide the approach to implement the custom behaviours using client-side code.


For the SharePoint Online Office 365, one is required to set-up the SharePoint Framework Development Environment and before doing it, there are some pre-requisites which there are to be followed.

  1. Office 365 tenant or Office 365 Developer program set-up
  2. For uploading and deploying the web-parts, one App Catalog site is required to be created.
  3. For testing the web-parts, one new Developer Site Collection is needed to be created.
  4. For quickly building and testing the app to have the exact solution, SharePoint Workbench provides the designer interface to developer.

SharePoint Framework Development Environment Setup

Set-up the environment by following below steps in sequential manner

  1. Developer Tools installation
    • NodeJS installation
    • Code Editor installation
  2. Yeoman and Gulp installation
  3. Yeoman SharePoint Generator installation
  4. Self-signed developer certificate trust

Follow this reference link for the step-by-step instructions on how to install the above mentioned components of the SharePoint Framework development environment.

SPFx Web-part

The SPFx web-part is a client-side component running in the SharePoint page context. It supports the HTML and JavaScript for building it. Also, it can be consumed in either SharePoint Online or On-premise environments.

Please refer the below examples for starting with it:

  1. Basic Hello World Web-part
  2. CRUD operation on a list
  3. Fetch images from a Library

SPFx Extension

A SPFx extension is like the SPFx web-part. It enhances the SharePoint end-user experience into modern pages and document libraries.

To start working with it, refer the below basic examples:

  1. Basic Hello World Extension
  2. Customize the header and footer


We have covered the fundamentals of the SPFx Development so, transform oneself from a beginner to learner. One can achieve the various complex custom requirement with proper combination of the modern JavaScript tools and libraries with the SharePoint Framework.

SPFx development can be carried out with Continuous Integrations or Continuous Development (e.g. Azure DevOps). It has other benefits like lightweight, performance, user-friendly, etc.

Microsoft is releasing new features on periodical basis for the modern site development so, it is preferable to go with the modern site instead of the classic site.


  • Leave a message...

Related Articles

Getting Started with Firebase – Cloud Firestore

Oct 23, 2020

An Introduction to key aspects of Internet of Things (IoT)

Oct 21, 2020

TransactionScope in C#

Oct 9, 2020