From the course: SharePoint Framework for Developers: 5 SPFx and Angular

An introduction to SPFx

From the course: SharePoint Framework for Developers: 5 SPFx and Angular

Start my 1-month free trial

An introduction to SPFx

- [Instructor] Now for the purposes of this course, I assume that you are already familiar with SharePoint Framework, but let's start with a basic introduction. The reason I have this introduction here is because I want to lead into the discussion of Angular. Let's get started. Okay, so classically we've had SharePoint On-Premises and SharePoint Online. We all know that the dev story for these has been entrusting. We had WSPs Farm Solutions not welcome anywhere, any longer, but we've had Farm Solutions as a way of delivering functionality on SharePoint On-Premises. The reality is that even Sandbox solutions are not really welcome anywhere any mmore. Add-ins, add-ins is another concept that was introduced by Microsoft. There were SharePoint hosted add-ins, there were provider hosted add-ins. We know that there are lots of differences between SharePoint hosted add-ins and provider hosted add-ins. Then in SharePoint Online we had Microsoft Graph and we used techniques such as Script Injection to do some amazing work. Then we had to deal with the differences of classic sites versus modern sites, with a different dev story between the two. Then there were other platforms to worry about and other extensibility scenarios. So the idea being that we haven't had a consistent dev story between on-premises and SharePoint online, right? We also haven't had an easy to install, lightweight development platform. Classically speaking, developing for SharePoint meant running this big heavy-duty virtual machine, and carrying this really heavy-duty laptop with me wherever I went. I was so jealous of my friends with their lightweight laptops that could run VS code and they could do amazing things with those. Why didn't SharePoint developers get any of that? Microsoft never uses the same tools internally that they asked us to use. Well until SharePoint Framework, now they use the same tools so they see the same issues that we do so they'll fix them. Let's be honest, historically we've gone down some bad roads. I've literally seen job descriptions with this word in them. Let's "unsharepoint" SharePoint. Looking for somebody who can "unsharepoint" SharePoint. That is the word to completely take over the user experience of SharePoint. Terrible idea, experience has shown us that this a bad idea. SharePoint Framework. Sure it is a consistent dev methodology between on premises and online. So the idea being that whatever you develop on-premises will move to online. The reverse may not be true because online will always be a super set of features of on-premises. Again because Microsoft is using this technology as well, so they will see the same problems that we do so we have a better hope of the problems getting fixed. Isn't that good? They like to call this a development experience on rails. They want you to customize and deliver value in SharePoint, but they want you to stay within rules and SharePoint Framewoek encourages you to do so. Best of all it is built on modern dev technologies. Typescript, npm, Yeoman, and any choice of JavaScript Framework. Any choice really? Let's dive deeper into that. So SharePoint Framework is JavaScript library agnostic, right, but yet there seems to be a lot of propensity to Word's libraries such as jQuery, React, and Knockout. Well there must be a good reason for that, right? Why do we not see Angular here? Let's find out.

Contents