Content Editor webpart Vs SPfx

Question

I want to know what's the difference between using content editor webpart and sharepoint framework, aren't they going to do the same thing?

Answer 1

If you're a disciplined and clever developer/team then the SPFx doesn't give you any functionality you couldn't develop yourselves In fact many companies have already developed their own framework like this. So in this sense SPFx is just MS catching up to what developers has already been doing for many years.

But it has a lot of functionality which "help" traditional SP-developers into a more modern web development world.

And it also brings a lot of structure into your client side development, which you had to have discipline to do yourselves.

On the other side it also has some downsides.

The Good Parts

Offline Development
In past, to build SharePoint customizations, you had to know .NET, install Visual Studio and the SharePoint developer tools, Running on Windows and having .NET installed. But using SharePoint Framework you can build solutions that consist 100% of JavaScript.

Tool chain
Full yeoman/gulp/typescript/mocha/... tool chain to scaffold and build your web parts.

But of cause you could/can build your own tool chain, using the same or other tools

Testing
It tries to guide developers into testing their stuff prior to production using the Workbench and unit testing.

But of cause could/can/should do that already.

Configurability
A standard way of allowing users to configure your web parts.

But of cause you could/can build your own configuration system which hooks into the tool panel

Module loader
A standard way of loading all dependencies for all web parts on the page.

But of cause if you control the development of all custom web parts, then you could/can do the same

Deployment
A standard way of deploying your web parts

But of cause you could/can do the same, by using some provisioning framework, maybe with provider hosted apps, which will also allow you to provision list, ... and give you a way of running with elevated privileges

The Bad Parts

Only works on O365/SP2016
SPFx only works on Office 365 and SP 2016 Feature pack ?+

Your own framework could/can work on any SharePoint version

Overkill for very small one time stuff If what you create is a very small one time thing, then using all of SPFx may be overkill

But if I had a penny for each time some small one time stuff has been copied/changed, then ...

But for the most part

It just the exactly the same development model.

Answer 2

I'll take another stab at this as well, although the responses so far cover various parts of this. This is a somewhat stream-of-consciousness post, so I apologize if it rambles a bit.

First - as you mention - SPFx, the Script Editor Web Part and the CEWP allow you to run script on a page. You can also do other things like custom actions that register script links. These are all basically different solutions to the problem of "how can I run js". The developer community has certainly shown that this is the preferred method of extensibility when there configuration is not sufficient. (Configuration being something baked into the system where an end user can say "the icon should be X" or "the colour should be Y"). So yes, at a fundamental level, it's all about getting js to execute.

However, how that js is registered and how it executes is where the main differences appear. First off has to do with the permissions to run script. I'll assume you are familiar with the concept of NoScript / Add and Customize Page. The point here being that many types of sites don't allow the user to register javascript at all. Most Self-Service sites (users my-site, self service team sites, etc.) are configured with no-script. This is because while you may be the site collection admin of your my-site, the admin doesn't want users to execute code in the context of a visiting user to a site. The current solution to this is to put all the execution behind an iFrame / Add-In with an explicit consent (either from the user or the admin) to allow access to data. SPFx solves this by allowing the admin to approve specific code from trusted developers for use in the tenancy, independent of the no-script settings. On a related note, leveraging SPFx gives admins the ability to globally control the execution / use of registered components, which is nice.

So, we now have script running on the page. That's cool. Now, currently each webpart developer is - to some extent - required to do a bunch of work themselves. They need to manage the digest cookie in case the page has been around for more than 30 seconds. If they require web properties and another control requires web properties, there is no real contract on how to share this data, so everyone fetches their own copy. That starts to become a problem. Additionally, it's a bit of a hurdle understanding how to make REST calls to SharePoint, managing the headers and auth, etc. It's certainly doable, but you need to dig around and read a bunch of posts to figure it out.

Ok, next up we have the usability / consistency of the webpart experience for the end user. The SEWP/CEWP is already using the configuration pane for it's own configuration. Ie, the SEWP edit experience hosts the script that you are editing. This means that the end user now needs to learn a bunch of different UI gestures, and it leaves a lot to the developer to do "right". Did they correctly handle the "save-before-navigate" data loss? Did they do the necessary work to handle accessibility / screen readers / etc?

What I like to think we've done is met developers where they want to work (js in the browser) and have created a bunch of things to make your life as developers easier, the lives of your end users better, and make admins more open to running your code. Note that this is an iterative process, we like getting feedback, and are looking to make the lives of all three groups (devs, users and admins) better.

Answer 3

I had been digging into SPFx lately and this is what I understood

1. Javscript injection(using content editor webpart) and SPFx are both development approaches to create form/view to connect to SP data(though possiblity are endless but for sake of this discussion limiting to SharePoint data)
2. Javscript injection(using content editor webpart) is not reusable, you have to add the code/js files etc to every page you want to use it.
3. Javscript injection(using content editor webpart) cannot have configurable values which typically a SP admin has to set while configuring a web part.
4. SPFx creates a webpart and it allows us to have a configurable webpart properties section at client side(this was only possible at server side by creating web browsable properties in webpart development model using visual studio)
5. Though Both approaches allows us to create functionality without visual studio development stack.
6. Developing, debugging and deploying a webpart via SPFx is pretty much easy due to workbench file concept(please go through SPFx documentation to understand what workbench file does)
7. SPFx creates webpart can be deployed to any app catalog and it uses app model concept hence you can create a app functionality which a site collection admin can add it via app catalogs... This is not possible in javascript injection(using content editor webpart).
8. Though we can use modern development open source tools via content editor webpart also but SPFx has made it easier for us to use this open source frameworks if it is required.

This is what I can think of, I will edit answer if came across any other advantage.

Answer 4

Something I haven't seen mentioned: the Content Editor Web Part only takes one parameter (the link to the code). The SPFx allows you to build not only the code but also the Web Part itself, including parameters if needed.

Answer 5

Here I can give you a brief idea but there is already lot on the web (i think):

SharePoint framework (#SPFx)

1. Client side webpart development framework which will enable you to develop a webpart using Modern Javascript toolchain (NodeJS, npm, Yeoman-generator, Typescript, Gulp etc) for building, debugging and deploying

2. Using SPFx you could get almost similar experience of developing server side webpart/apps, however you write everything in JavaScript so there are some limitations. You get some of the goodies like access Site, List, User Object for code completion whilst developing, see code bugs while developing, debugging, Apps need permission to access to SharePoint site artefacts, Property panel to configure app settings like traditional webpart etc.

3. Webparts/Add-in you develop are reusable for instance you could build Accordion, Tabs, Image carousel Apps backed with SharePoint data in list or library. There is also some work in the pipeline to communicate to Office Graph, Azure AD Apps etc.

4. Webpart versioning can be managed more efficiently (e.g. 1.0.0.0) and roll out app updates easily.

5. Using SPFx apps are developed and hosted in app catalog in SharePoint online tenant (no app store at the moment), but in the feature there is every chance that commercial Client-side apps/webparts can be hosted and purchased through store.

6. It is very easy to use External framework like React, AngularJS, JQuery and KnoutJS

7. SPFx is a new app model development using complete JavaScript

Microsoft says - they are using/being using SPFx to build new modern look list, library, site content pages etc. so other developer can get the same experience like developer in Richmond, USA (Microsoft) are getting to build functionality in SharePoint online/2016

Content editor webpart:

1. You could develop client-side app in JavaScript and embed scripts but you might run into issue like cross-site scripting, access permission issue etc.

2. It's very difficult for site editor to re-use and configure the client-side app built in native JavaScript because there will be no Property pane to configure etc.

   3. No easy versioning capability or managing app updates

   4. You don't get a rich experience for developing apps in native JavaScript. There is no app model behavior for development.

Personally I have developed lot of apps in JS (AngularJS etc.) and provisioned through Content editor webpart, but through SPFx I feel like I develop apps properly for SharePoint.