Client & Server-side technologies comparison:
In old-school SharePoint, the development was mainly on the server side with C#, .Net Framework & SharePoint object model. But now, to suit modern development strategies where we can develop, host, and access applications on the cloud, SPFx uses modern technologies for development. Following is the comparison of old & new tooling chains.
SPFx vs. Script Editor Web parts vs. App Parts
This is one of SharePoint’s most popular web parts, in which developers can inject script into the SharePoint page. We can interact with DOM elements with this approach. But there are some cons:
- The end-user can edit the page & modify the script, so it is not safe.
- The configuration options cannot be provided quickly.
- There are certain cases where the "NoScript" feature is enabled for specific site collections. So, the script editor web part will be blocked from such sites.
This is an option for solutions that run "NoScript" sites, which was introduced in SharePoint 2013. It creates an iFrame where the experience resides & executes. This will require separate authentication & we will not be able to access DOM elements with this, thus secured.
But there are disadvantages to this too:
- Also, making responsive designs and inheriting CSS & theming information will be more difficult.
- Not being able to access DOM elements is a disadvantage because we may need to interact with the elements on the SharePoint page.
SharePoint Framework: -
The new SPFx model solves the issues in the above two options & also its popular because of the following features: -
- Open-source tooling: SPFx is an open & connected platform. It leverages all the open-source tools & can be installed on any machine.
- SharePoint 2019 On-Premise Customization: The new SharePoint Server 2019 can utilize modern SPFx features to build & deploy solutions.
- Deploying SPFx web parts as MS Teams tabs: SPFx v1.8.0 onwards, SPFx web parts can be added to Teams as tabs with little customization. This allows utilizing web parts more & gives them more exposure.
- Library Components, a new feature: Developing reusable code that can be shared & reused among many components can be beneficial. SharePoint Framework provides this feature to create standard services that many web parts can utilize.
Power Apps VS SPFx: When to use what: -
Power Apps is a low-code development component of Microsoft's Power Platform. We can build custom business apps that can connect to various online & on-premises data sources (Microsoft 365, SharePoint, SQL Server & so on). As Power Apps is also becoming popular with an increase in the number of users due to its rapid application development, let us compare it with SPFx solutions: -
|Category||Power Apps||SharePoint Framework|
|Performance||Even for small applications, the load time taken by Power Apps is more.||Performance is better than Power Apps. Small or large-scale applications load quickly compared to Power Apps.|
|Data Connections||Multiple out-of-the-box connectors are available for connecting with various data sources, making the process easy.||Data Connections require a bit more setup to be done in SPFx, but they can be tailored to do exactly what you want.|
|Time to build||Power Apps takes less time to build apps/forms than SPFx as it is a low-code solution.||SPFx takes more time to build the apps/forms/solutions as more development efforts are required.|
|Size of applications & Customizations||Suitable for small-scale applications. Even though there are customization options, you will not have complete control over them.||Suitable for small & large-scale applications, it can be fully customized. But for small applications, development efforts & time required can outweigh the benefits.|
Counter View: Customer Success Story: SharePoint Designer Workflows migration to Power automate and Power apps
What can you build with the SharePoint Framework: -
With SPFx, we can build three things: Web parts, Extensions, and Library Components. And these include sub-components too.
- Web parts: -
- Extensions: -
Extensions allow developers to extend or augment the SharePoint user experience for modern pages & document libraries. This can be useful for branding across sites in the entire tenant. SPFx includes three types of extension: -
- Application Customizers:- This enables developers to add scripts across SharePoint pages and access HTML placeholders on the page, e.g., header & footer placeholders. It can be used for branding across sites.
- Field Customizers:- A Field Customizer allows us to create modified views to data for fields & columns within a list or library. For example, we can use it to display colored bars or a KPI instead of a text-based percentage in a field to have a more engaging experience.
- Commands Sets:- Command Sets help in creating custom commands for lists & libraries. It allows adding new actions by extending the command surfaces of SharePoint
- Library: -
A library component allows creating of shared code that can be referenced & used among all components in the tenant.
- Microsoft Teams Solution: -
The SPFx web parts can be used to develop custom apps for Microsoft Teams. A web part's manifest file can be updated to indicate that it can be used as a Microsoft Teams tab. This way, a single web part can be added to the SharePoint page and the Microsoft Teams custom app.
Single Page Apps (SPAs): -
The Single Page Apps are just significant web parts that are added to the page. They act as an application; no other web part can be added to the page. Developers can create SPAs by simply creating web parts & setting a string in the manifest file to indicate a SPA.
Like all other development models, there are some downsides for SPFx too: -
- Elevating Permissions: As SPFx solutions run in the current user's context, like any other client-side solution, there is no inbuilt option to elevate permissions for impersonating another user.
- Long-running operations: As SPFx is entirely a client-side implementation, it is not suitable for long-running operations. The web request cannot wait longer for the response. So, for such processes, a hybrid solution will be helpful, where extended operations can be implemented in Azure web jobs & SPFx can get updates via webhooks.