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?
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
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
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.
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
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
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.
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.
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.
I had been digging into SPFx lately and this is what I understood
- 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)
- 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.
- Javscript injection(using content editor webpart) cannot have configurable values which typically a SP admin has to set while configuring a web part.
- 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)
- Though Both approaches allows us to create functionality without visual studio development stack.
- 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)
- 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.
Here I can give you a brief idea but there is already lot on the web (i think):
SharePoint framework (#SPFx)
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.
Webpart versioning can be managed more efficiently (e.g. 184.108.40.206) and roll out app updates easily.
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.
It is very easy to use External framework like React, AngularJS, JQuery and KnoutJS
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:
No easy versioning capability or managing app updates
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.