11

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?

1
  • This is really OT bt it has some value. Converted to a community wiki. Oct 27, 2016 at 19:39

5 Answers 5

12

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.

3
  • 2
    +1 for SPFx is just MS catching up to what [Front-End] developers have already been doing for many years. Oct 23, 2016 at 8:29
  • I'll add one additional feature of SPFx, which is that because it can have admin approval, you will be able to run solutions (client side webparts for now, more in the future) on sites that have NoScript enabled (or Add/Customize Pages disabled, if that's the way you think). Oct 24, 2016 at 16:55
  • this observation are correct but one thing missing here is creating app is better in terms of re-usability than JavaScript injection...also though currently it is only supported in office 365 and SP online, they have plan to support in on-premise also. Oct 25, 2016 at 19:00
4

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.

9
  • Have there been thoughts about getting away from that (2001) "WebPart" concept where the (webpart)definition is stored IN SharePoint? And what is the teams view on WebComponents? Oct 27, 2016 at 19:42
  • 1
    [slept a night on this response, because I know myself, and the response would have included words like 'Marketing talk' and 'BS'] Quote: "What I like to think we've done is met developers where they want to work" Feedback: "But you took away User Custom Actions-ScriptLinks and JSLink, so you took away 70% of how we massage SharePoint in what we want it to be. Please gives us back script access into the Modern Experiences" Oct 28, 2016 at 7:19
  • Note: ScriptLinks did work in the first releases of theModern/New Experiences, so it is not an 'iterative proces' where functionality is not developed yet. Oct 28, 2016 at 7:31
  • A couple of questions. In #1, I'm not sure of what you are exactly getting at with "getting away from the webpart definition being stored in sharepoint". Could you explain? For the question around how custom scripts / jslink were used in the past - Yes. Working on it. Oct 28, 2016 at 19:03
  • WebPart definitions are still stored IN the SharePoint database, and it is still the back-end pushing (scaffolding) content to the Browser. If you think of a "webpart" as just a bit of DOM real-estate that needs content there doesn't seem to be any need for a back-end, other than it being a container for data. WebPart properties are then just metadata on a WebComponent(?). WebParts can just be an HTML5 file in a Library. SPFx (the dev stack) is cool but it kills participation of Generation J(Query) who can't program, but can copy/paste/alter HTML5. They used the CEWP for that. Oct 28, 2016 at 19:26
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.

4
  • 3
    #2 is not correct. Linking to a .html file allows you to reuse the same code over and over and over again. #6 is completely subjective. I prefer to debug JS directly in the browser dev tools. #8 ??? Are you referring to the usage of NPM? Front-end devs have been using this for years.
    – iOnline247
    Oct 27, 2016 at 2:51
  • 1
    #2,3,6,8 if you get the URL right you can edit (CEWP linked) JS and HTML files with the (new) OneDrive file editor; which does syntax highlighting and more. It aint VSCodeOnline but pretty cool one-click to change code: https://[domain].sharepoint.com/sites/[site/library]/Forms/AllItems.aspx?id=[relativefileUrl]&parent=[folder]&p=5 Oct 27, 2016 at 19:50
  • @Danny'365CSI'Engelman, can you give us more info on this OneDrive editor URL construciton, please? I've tried various combination and count not make it work. Oct 28, 2016 at 0:11
  • Put a JS file in a (modern/new) Library and open it (it will open in the (new) Editor). You will get the above URL. For HTML files you have to massage the required data into the URL yourself and open it with code or AHREF ; the OneDrive code will not deliver an HTML with the correct mimetypeheaders (so your browser will download it as an unknown file, as SharePoint has treated HTML files for all its life) BUT get the URL right and the Editor will open in HTML mode with syntax highlighting and all Oct 28, 2016 at 7:37
0

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.

2
  • 1
    [Disclaimer I love the CEWP and am still not smitten with SPFx] The CEWP is IKEAs Billy cabinet you can assemble with one screwdriver. SPFx is IKEA giving you a pile of wood and requiring you to master all skills AND demands you only use Snap-On and DeWalt tools Oct 27, 2016 at 19:29
  • 1
    @Danny'365CSI'Engelman how is this comment related to the specific point I highlighted in my answer?
    – Christophe
    Oct 27, 2016 at 19:57
-1

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.

    1. No easy versioning capability or managing app updates

    2. 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.

1

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.