My organization has decided to move to Sharepoint online so we need to re-create our custom traditional webparts with a technology that is compatible with SP online. I can either go with Add-in model or Sharepoint framework but I am not able to decide on which model I should put more efforts. Which is better?

1 Answer 1


If you are building webparts in SharePoint Online, then SharePoint Framework is the way to go. SharePoint framework solves one of the main problem (among many other problems) with Add-in webparts which is webparts are loaded in iframe, which causes poor loading experience.

Why you should NOT use Add-in model for webparts?

The current option for solutions that run in NoScript sites is the add-in/app-part model. This implementation creates an _iFrame _where the actual experiences lives and executes. The main strength here is that since it is external to the system and has no access to the current DOM/connection, it is easier to trust and deploy for information workers. They can be installed on NoScript sites by end users.

There are a couple of downsides though. First, they run in an iFrame, which has a collection of issues associated with them. They are slower than the script editor web part, as it winds up being a completely new request to another page. This page has to go through authentication and authorization, make its own calls to get SharePoint data, load various JavaScript libraries and more. Whereas a script editor might typically take, for example, 100ms to load and render while an app-part might take upwards of 2 seconds or more. Additionally, the _iFrame _ boundary makes it more difficult to create responsive designs, inherit CSS and theming information, etc. However, it does have a heightened sense of security, which can be useful from the developers perspective (my page is inaccessible by other controls on the page) and from the end users perspective (the control has no access to my connection to Office 365).

Additionally, neither of these solutions work for the product team itself. The product team historically created web parts as full trust C# assemblies that were installed on the cloud servers. However, the majority of our current development work is almost entirely JavaScript running in a browser making REST API calls to the SharePoint and Office 365 back end workloads. C# assemblies don’t work in this world, so we also needed an updated development model.

Why should SPFx be used?

  • It runs in the context of the current user and connection in the browser. No iFrames.
  • The controls are rendered in the normal page DOM. The controls are responsive and accessible by nature.
  • There is a life cycle that the developer is involved in. It’s not just render, but load, _serialize _and deserialize, configuration changes, etc.
  • It is framework agnostic – You can use any browser framework that you like – React, Handlebars, knockout, angular – take your pick.
  • The tool chain is based on common open source client development tools like npm, TypeScript, yeoman, webpack, gulp, etc.
  • Performance is key.
  • SPFx client-side solutions that are approved by the tenant administrators (or their delegates) can be used by end users on all
    sites – even self service created sites like teams, groups, personal, etc.
  • Can be deployed in both classic web part and publishing pages as well as the modern pages.

Source for above excerpt is here

You can read more about design considerations for building your webpart here


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.