Introduction to SharePoint FrameWork - Part 1

   Introduction

         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. With the SharePoint Framework, you can use modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile-ready from day one. The SharePoint Framework works for SharePoint Online and also for on-premises (SharePoint 2016 Feature Pack 2).

     Key features of the SharePoint Framework:        

• It runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly to the page).
• The controls are rendered in the normal page DOM.
• The controls are responsive and accessible by nature.
• It enables the developer to access the lifecycle in addition to render, load, serialize and deserialize, configuration changes, and more.
• It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.
• The toolchain is based on common open sources client development tools such as npm, TypeScript, Yeoman, webpack, and gulp.
• Performance is reliable.
• End users can use SPFx client-side solutions that are approved by the tenant administrators (or their delegates) on all sites, including self-service team, group, or personal sites.
• SPFx web parts can be added to both classic and modern pages.

Why the SharePoint Framework?

         SharePoint was launched as an on-premises product in 2001. Over time, a large developer community has extended and shaped it in many ways. For the most part, the developer community followed the same patterns and practices that the SharePoint product development team used, including web parts, SharePoint feature XML, and more. Many features were written in C#, compiled to DLLs, and deployed to on-premises farms.

             That architecture worked well in environments with only one enterprise, but it didn’t scale to the cloud, where multiple tenants run side-by-side. As a result, we introduced two alternative models: client-side JavaScript injection, and SharePoint Add-ins. Both of these solutions have pros and cons. 

• JavaScript injection

• One of the most popular web parts in SharePoint Online is the Script Editor.
• You can paste JavaScript into the Script Editor web part and have that JavaScript execute when the page renders. It’s simple and rudimentary, but effective. It runs in the same browser context as the page and is in the same DOM so it can interact with other controls on the page.
• It is also relatively performant, and simple to use.
• Here are a few downsides to this approach, however. First, while you can package your solution so that end users can drop the control onto the page, you can't easily provide configuration options. 
• Also, the end user can edit the page and modify the script, which can break the web part. Another big problem is that the Script Editor web part is not marked as "Safe For Scripting".
• Most self-service site collections (my-sites, team sites, group sites) have a feature known as "NoScript" enabled. Technically, it is the removal of the Add/Customize Pages (ACP) permission in SharePoint. 
• This means that the Script Editor web part will be blocked from executing on these sites.

• SharePoint Add-in model

• This implementation creates an iFrame where the actual experience resides and executes.
• The current option for solutions that run on NoScript sites is the add-in/app-part model.
• The advantage is that because it's external to the system and has no access to the current DOM/connection, it's easier for information workers to trust and deploy. 
• End users can install add-ins on NoScript sites.
• There are some downsides to this approach as well. First, they run in an iFrame.


• iFrames are slower than the script editor webpart because it requires a new request to another page. The page has to go through authentication and authorization, make its own calls to get SharePoint data, load various JavaScript libraries, and more. A Script Editor web part might typically take, for example, 100 milliseconds to load and render, while an app part might take 2 seconds or more. Additionally, the iFrame boundary makes it more difficult to create responsive designs and inherit CSS and theming information.


• iFrames do have stronger security, which can be useful for you (your page is inaccessible by other controls on the page) and for the end user (the control has no access to their connection to Office 365).

End-user benefits of the new SharePoint framework

              The new SharePoint Framework (sometimes referred to as SPFx now) is really only for developers, in most cases. End users really shouldn't care whether their developers are building things in an "old? way or a "new? way as long as what they get meets their requirements. 

SharePoint Framework - Open and Connected Platform

SharePoint Framework Pros and Cons

• Client Side: As discussed above, the server side solutions can damage a site collection to an entire SharePoint farm when not used wisely, whereas the risk eradicates when using client-side technique.


• Fast, Lightweight and Responsive: SPFx uses NodeJS and is completely client side so makes it fast and mobile-ready. Also, SPFx is fully compatible with Office Fabric UI, which makes it responsive as well. Altogether, the framework is consisting of all the latest web development technologies.


• Run on User Context: Since the complete framework runs on user context, so only permissible item to a user will be shown.


• Works in Classic as well as Modern Pages: The advantages of SPFx is that it works on both modern as well as the classic page. So, either your online tenant is running on old SharePoint 2013 site collection with classic mode only or you upgraded to latest tenant feature, be relaxed, SPFx covered these.


• Custom Properties: Earlier when a user had to write client-side code, they need to create extra variables and makes fetch calls to get those configurations. But now, with SPFx this comes in a very handy way, where a user can create properties for client-side web parts and configure it as per need.


• Deployment Mechanism: With SPFx, finally SharePoint provides a deployment mechanism. The deployment mechanism consists of bundling the app, packaging the app, shipping the app to store (or to local SharePoint App Catalog) and with proper permission, one can deploy it to their tenant. This provides a better way to manage client-side component.


• Scalable: As mentioned above, SPFx is not limited to SharePoint, a user can take advantages of NodeJS (backbone of SPFx) and can use any of the component available in NodeJS by community (not SharePoint but NodeJS community). Also with the development of Microsoft Graph API, a user can make their web part interact with rest of the Office365 including Azure, One Drive, Outlook etc.


• Remote Development: I hate most was the development environment. One must have a Windows Server OS running with SharePoint configured on it and the only development tools available was Visual Studio. This environment requirement bothers me a lot. SPFx comes with a fully client-side development approach, i.e. you can develop the component on any machine wither it runs on a Windows, Mac or Linux. And of course, you don’t need to have Visual Studio even to develop SPFx web parts, all you require is a simple text editor of your choice and you are good to go (obviously, you have to install the environment though i.e. NodeJS, Gulp and Yeoman template of framework)


• Local Workbench: Even if you are not connected to the internet, don’t worry, you can still develop on SPFx as it comes with a local workbench. The local workbench is capable of developing and testing the client side web part.

Cons:

• Everything is client side: Since everything is client side, creating business critical web part using SPFx is not what one must prefer. The client-side web parts are easy to reverse engineered and one can easily extract your business logic as its all JavaScript at the end of the day.

• New Environment: For classic SharePoint developers (i.e. majorly worked on Farm Solution, C# client object model only), it’s a completely new thing. Starting from NodeJS to Typescript to Webpacks, to gulp everything will be new to classic developers.

                    SharePoint Framework is open source and maintained by open source community. As of now, the SharePoint Framework can deliver fully functional client side web parts. But considering the development of new APIs by Microsoft, like Microsoft Graph API, one can leverage the SPFx to manage the entire cloud service starting from SharePoint to Outlook, OneDrive, OneNote, and even the Azure and list will keep continuing.

Conclusion

      This was the first steps to get in touch with the SharePoint Framework development model. We learned why MS introduced the SharePoint framework. what kind of tools are recommended, Pros and cons of SPfx. 

               In one of the next Blog posts, I will try to describe how to configure development environment for SharePoint framework. So far, happy coding!