State of SharePoint Client Side Development | December 2020

In this post, I'll give you an update on where we are with popular frameworks and tools developers use in the client-side SharePoint development world.

By Last Updated: June 24, 2024 7 minutes read

As we near the end of 2020, I wanted to take a look at where we are with respect to the State of SharePoint Client-Side Development. In this post, I’ll give you an update on where we are with popular frameworks and tools developers use in the client-side SharePoint development world.

Many of the things I’ll cover were recently touched on in the most recent Microsoft PnP SharePoint Framework & Client Side Development Special Interest Group (SIG) meeting, held on December 3, 2020. You can watch the recording of that meeting below:

SharePoint Framework

The current published version of the SharePoint Framework is v1.11, released in July 2020. While Microsoft originally was planning to release v1.12 before the turn of the new year, that is no longer the plan. As it stands, v1.12 is estimated to ship in January 2021.

What will this version include? Don’t expect to see anything new to be introduced in this version as it’s mostly expected to be a maintenance release.

Access page structure via an API

Earlier this year, in October, there was a significant change in SharePoint Online (SPO) that impacted quite a few customers. At the present time, there’s no supported way to determine if a web part is rendered on a page as full width or within a boxed zone. SPO was including some empty CSS classes to indicate as such. While Microsoft explicitly states the page DOM is not an API, detecting the presence of these classes was the only way to determine how a web part or SPFx component was rendered on the page.

In October, Microsoft embarked on a “cleaning” of the CSS and removed these classes, breaking many vendor solutions for many customers (see #6380: Changes to the DOM which affects SharePoint solutions). This created quite a stir that resulted in Microsoft rolling back the CSS changes while the looked for a solution.

The proposed solution is that in SPFx v1.12, Microsoft will introduce a supported API developers can use to detect the page structure, providing the same capabilities to solve the same purpose the CSS classes were serving.

Support for complex Teams solutions for SPFx solutions

While listed in the update for what’s coming in SPFx v1.12, it’s not entirely clear what this means. Today, you can use SPFx web parts as tabs & in personal apps in Microsoft Teams, and you can create Message Extensions (developer preview). This update will add the ability to include your own Teams app manifest file that will be used, instead of the auto-generated one, when you sync your app to teams.

There are a lot of known issues with using SPFx in Microsoft Teams, so maybe this means known bugs are going to get fixed? We’ll have wait and see.

Move to MSAL.js v1 from ADAL.js

This was not listed in their update, but one change that has already happened in SPO is the SPFx team has updated the service to replace ADAL.js to now use MSAL.js v1. According to Microsoft, this has been rolled out 100% in SPO & had no impact on your code as it’s “plumbing work”. In other words, this isn’t related to v1.12 in any way & no action is required on your part.

We’ve been dealing with a lot of known issues related to calling secured endpoints from SPFx, including Microsoft Graph and others using the AADHttpClient & MSGraphClient APIs like tokens timing out and other issues.

You might wonder: What about MSAL.js v2? About two months ago, Microsoft stated they were first making the change to MSAL.js v1 as that involved quite a few dependencies and a complicated rollout. Updating to MSAL.js v2 was going to come later partly because some things needed to be addressed by Microsoft Entra ID to address some issues with MSAL.js v2. But like the move to MSAL.js v1, these shouldn’t impact 3rd party developers as it’s just “plumbing work”.

Looking forward

In the SIG meeting last week, Microsoft listed a bunch of stuff in their “looking forward”… there wasn’t a lot of context around these things. They included:

  • Perf improvements (runtime & build time)
  • Integrated development tools (???)
  • Specific guidelines & samples
  • Ability to disable app only ACS access tokens
  • Microsoft Teams improvements
    • Acquire solutions from the store
    • Support for complex scenarios (how this differs from what’s listed above in v1.12 is unclear)
    • Additional support for mobile experiences
  • Inner loop improvements
    • Updated 3rd-party toolchain (???)
    • Enhanced capabilities on the hosted workbench

But what about…

What’s missing from the list of changes Microsoft is looking at are things you see developers asking about.

SPFx is still only supported on Node.js v10. That version is TWO MAJOR VERSIONS behind the current active LTS version, Node.js v14. When will the SPFx dev tooling get updated to support a modern Node.js version? Yeah, I get v10 is still supported, but only through April 2021.

And what about replacing TSLint with ESLint? In February 2019, it was announced TSLint was deprecated & efforts would focus on ESLint. In fact, the TSLint project site even states: “typescript-eslint is now your best option for linting Typescript”. It’s been 20 months since that statement… so… how about update?

I hope 2021 brings a better story for SPFx… today it feels like the house on the corner with broken windows and the overgrown yard that people aren’t committed to the upkeep. There are lots of known bugs around auth, SPFx extensions breaking in SharePoint lists, SPFx solutions not working in Microsoft Teams like they are supposed to, and a dated platform. In late 2019 & early 2020, Microsoft was talking about wanting to ship updates to SPFx more often, yet we saw only two releases in 2020 (v1.10 in January & v1.11 in July) after four releases in 2019.

Important: Use ESLint in SPFx projects!
Learn how you can use ESLint in your SPFx projects: Get with the times & ditch TSLint in favor of ESLint in SharePoint Framework projects & [Ditch TSLint for ESLint in SPFx projects in one simple step]({< ref “” >}).

PnPJS (v2.0.13)

This JavaScript library is a popular SDK abstraction layer on top of the SharePoint REST API for server-side & client-side JavaScript based solutions.

In their latest release, they added support for using MSAL.js for local development and tests (see PR#1454) and they updated their GitHub actions to use MSAL auth as well.

Their next release, v2.1.0, is coming soon and currently available in beta. This release will introduce isolated runtimes which will be great for developers using Node.js where you want to connect to more than one tenant at the same time, something commonly needed in multi-geography scenarios.

PnP SPFx Generator (v1.15.1)

The most current version of the PnP SPFx generator, a replacement for the Microsoft provided Yeoman generator, yo @microsoft/sharepoint, adds additional support for web frameworks, testing suites and other features than what we get in the OOTB generator.

The currently release added support for Angular 10 as well as the Microsoft Graph Toolkit.

PnP React Controls (v2.2.0)

This suite contains reusable controls that you can use in your SPFx React-based solutions. The current release added improvements to the RichText, FilePicker & TaxonomyPicker controls as well as addressed some issues around localization.

PnP Property Controls (v2.2.0)

Like it’s sibling project above, these reusable controls can be used in SPFx web part property panes. This most currently release introduced a new Microsoft Teams picker control and also addressed some issues around localization.

PnP Modern Search (v3.16.0)

This project is a collection of multiple web parts that enable users to implement customizable search-based solutions. This most recent update includes added support for Danish & German languages and includes multiple fixes.

The next version of Modern Search, v4, is currently available in preview. It supports using the Microsoft Graph Search API as well as the SharePoint Search API, and is built to be more reusable than with a modular & extensible design. You can hook up your own custom backend and use additional renders for the results beyond the native support for Handlebars that it currently has.