 Hey, I'm Andrew Connell. This video is one of the chapters from the free starter bundle of my Mastering the SharePoint Framework course by Voitanus. You can find the other free videos from the starter bundle that are listed in the description below. And that course contains over 35 hours of in-depth explanation and instructor led demos all by me that teaches you everything you need to know about the SharePoint Framework or SPFX and to become a master at it. I offer the course in three different bundles. The starter bundle, that's everything I've already mentioned, as well as two other bundles, the fundamentals bundle and the ultimates bundle. Each bundle contains more content than the previous bundle and some additional resources. You can learn more about the course on my site that's linked here as well as linked in the notes in the description below. Now with the context set, enjoy the rest of this chapter. Hi, welcome back to the course. This is the second chapter of my free starter bundle on my course, Mastering the SharePoint Framework. And in this chapter, I wanna introduce you to the SharePoint Framework. You may be brand new to the SharePoint Framework, also known as SPFX, and you also may have a little bit of an understanding on what it is. But depending on your level of knowledge, if you might wanna skip this chapter or some of the lessons within this chapter, just let me explain to you what we're gonna cover in these different lessons so you can make that decision. Now I'm gonna start with a reflective look down memory lane at the history of SharePoint and explore how we got to where we are today in the SharePoint Development world. I think having some perspective on why we have this current development model helps you understand the SharePoint Framework and how it fits and why Microsoft created it. Then I'm gonna introduce you to the SharePoint Framework. And my goal in this lesson is for you to understand what the SharePoint Framework is and just as important what it is not. The SharePoint, this introduction is capped off with a demo seeing how to work with components authored using the SharePoint Framework from an end user point of view. Now after exploring the SharePoint Framework, we're gonna compare it to the previous options that were available to us, such as for SharePoint Developers, such as comparing and contrasting it so that you have an idea of what makes the most sense for the task at hand. And then at the end of this chapter, I have a lesson that's gonna explain all the different places where you can go to get documentation, resources, both from Microsoft and the community and get additional help when you're working with the SharePoint Framework. Now the notes for this last lesson is gonna have a lot of additional links for you to check out and evaluate. From different groups on social media platforms to public forums, chats and communities, I'll keep updating the notes as the options change over time. Also make sure you check the comments out because I'm seeing students add some stuff as well. How does that sound? Sound good? Fantastic. So let's go ahead and dive in and get started with this chapter. I'll see you in the next lesson. Hello and welcome back. Now in this lesson, I wanna take a look at where we've been and how we got to this point of SharePoint Development. It's a walk down memory lane. Now when looking at a new paradigm such as the SharePoint Framework, I really find that it helps when you put it into context and understand the motives, the challenges and the reasons why someone created it, in this case, Microsoft. The first version of SharePoint that was arguably embraced by developers was SharePoint Portal Server 2003. Sure, there was a SharePoint Portal Server 2001 and SharePoint Team Services 2002, but SharePoint Portal Server 2003 and its free cousin SharePoint Team Services 2.0 that it was based on, these were the versions that developers started to customize. This is where I started with SharePoint long time ago. It was the first version that embraced the .NET Framework and now when I say it was embraced by developers, I use that term very, very loosely. There was no development model. The API wasn't really documented and thus you spent a lot of time reflecting DLLs on the server trying to figure out how things worked. You could do it, but it was tough. Everything that you created utilized the server side API that Microsoft used to implement the rendered pages for SharePoint Portals, Areas and Sites. Now back then, we had no client side API. We only had a server side API. So all of our customizations, they ran in the same context as the SharePoint process. And this meant that our customizations ran in full trust and could do anything that they wanted. But unfortunately, this also meant that we could create customizations that crashed the entire SharePoint process. And the other challenge too was that there was also no special deployment model for getting our customizations into SharePoint. Everything had to be X copied to the server and put in the correct locations. And this is true not only for compiled things that we created like controls that went on the page, but also for new ASPX pages, CSS files, images, JavaScript files that we used to implement new site definitions or templates. In fact, we had to make sure these things were on every single server in our farm. Microsoft took notice of developers trying to make these customizations and invested in this for the next version. The next version, Office SharePoint Server 2007, also commonly known as Moss 2007, and the free version that it was based on, Windows SharePoint Services 3.0 or WSS V3. Now this version still only featured a couple different things. It still only had a server side API. So any customizations that we created had to be deployed to the server because we didn't have a client side API. This meant that our customizations continued to run in full trust with the same context as the SharePoint process. And yes, this also meant that we as developers could do quite a few things, but unfortunately that also meant that if our customizations failed, we also could crash the entire SharePoint process on the server. Now this version did introduce two concepts that had significant and long lasting impacts on SharePoint developers. The first was a plugin model that was introduced into SharePoint. And these plugins were called features with a capital F. These enabled developers to do things that weren't easy to do previously. This included things like provisioning lists and other artifacts in our SharePoint environment. The other concept that was introduced in this version is something called a solution. And a solution is a special kind of a file that acts as a package for all customizations to be deployed to the SharePoint server. And in fact, one solution uploaded to a single server in a SharePoint farm would deploy those customizations to all the servers throughout the entire farm. Now, these two additions to SharePoint triggered a wave of SharePoint development and extensibility projects across the industry. We saw a wave of projects and tons of job opportunities open up across the industry. If you were around this business in 2008, 2009, you won't remember how crazy these days were. Business was really good. But this also triggered a wave of SharePoint deployments for customers. And up into this time, companies were responsible for standing up and hosting their own SharePoint deployments. If you recall, this was not a trivial task. Running a SharePoint deployment, that was a big job. It was quite a significant task. So some customers started looking for hosting options and naturally, Microsoft wanted to answer this request from some of their larger customers. But this new business model of hosting SharePoint for enterprises, it brought along a bunch of challenges. And it wasn't as cost effective for one SharePoint environment and deployment to host a single customer. So Microsoft started looking at multi-tenant hosting options. Multi-tenant refers to using the same SharePoint deployment to host two or more customers. But the way we were developing and extending SharePoint up to now using highly trusted customizations or otherwise referred to as full trust, that was posing a really big problem. A single bad customization could bring down an entire farm, not just for the customer that rolled out the change, but also for all the other customers that were relying on that same physical server. This thinking drove a lot of the design decisions with the next version of SharePoint, SharePoint Server 2010. Now, SharePoint Server 2010 was based on its free cousin, SharePoint Foundation 2010, which really is just a new name for Windows SharePoint services that we had in the previous version. So you could think of it as WSS-4. Now this version introduced a lot of multi-tenant capabilities to SharePoint and it was around this time that Microsoft started offering the beginnings of their Office 365 or SharePoint online offering. At the time we called this B-Pause, which stood for the Business Productivity Online Services and Microsoft was beginning to get into the hosting business. Now for developers, SharePoint Server introduced a new development paradigm that we called Sandbox Solutions and these were also called partially trusted solutions because they didn't communicate directly with SharePoint. Instead, they went through, let's just call it a proxy, that filtered what they had access to. Now this proxy, it really served two purposes for us. First of all, it kept Sandbox Solutions from accessing parts of the server-side API that customers in a hosted environment should not have access to, such as deleting websites on the web server or programmatically deploying custom code. The proxy also created a barrier to the core SharePoint process. So if I built a customization and it crashed, it wouldn't affect the rest of SharePoint and thus the other customers that are on the same physical servers that I'm on. It would only affect me. Now the non-Sandbox Solutions we were used to creating prior to SharePoint Server 2010, we now had a new name for these things. These were called fully trusted solutions and they were still allowed and supported in SharePoint Server 2010, but unfortunately this new partially trusted model was not terribly well received by the community. The challenge was that these Sandbox Solutions were too limiting. The proxy or the Sandbox Execution process in which they ran where they ran things only had access to an API within the site collection where they were currently running. And so this kept a lot of developers from doing the things that they were used to doing with fully trusted solutions and it forced Microsoft back to the drawing board but more on that in just a minute. Now it's worth noting that in SharePoint Server 2010 we saw the introduction of the first, well the first real modern client-side API, the client-side object model that we referred to as the CSOM. This was offered as a JavaScript and a managed code library. Developers could use some of the CSOM to perform some operations in SharePoint from off the SharePoint Server for the very first time. Now to be honest, prior to this, SharePoint had some SOAP based web services that some of us could use, but they weren't as easy to use in some popular open source projects popped up to simplify working with them. You might have occurred a popular project by a friend of mine called SP Services. Thanks Mark Anderson. Now the next release of SharePoint was SharePoint Server 2013. SharePoint Server 2013 was based on SharePoint Foundation 2013. And in this version, Microsoft heavily invested on making SharePoint multi-tenant at the core. This version was designed to be the workhorse for the hosted SharePoint offering, SharePoint Online in Office 365. This version of SharePoint took the work Microsoft had done in the previous version on client-side APIs and they seriously stepped up their investment. They added a lot of capabilities to the CSOM API, but also made tremendous investments in a new REST-based API. The vastly improved client-side APIs were just part of the development story changes that we saw in SharePoint Server 2013. While SharePoint 2013 still supported both farm solutions and sandbox solutions, well, the hosted version of SharePoint only allowed us to use sandbox solutions and blocked farm solutions for the understandable reasons. We also saw a new development model. Microsoft pivoted from the solution model of development and introduced a brand new option, the SharePoint add-in model. Actually, when it was rolled out, it was called the SharePoint app model, but it was renamed a few months later when Microsoft ran into issues using that name with their Office clients and its app model. The new model embraced developers to create two types of customizations. We had SharePoint-hosted add-ins and SharePoint-hosted add-ins, these were customizations that were deployed and hosted within SharePoint sites, but SharePoint-hosted add-ins, they didn't support any compiled code that would run on the server. Instead, developers created client-side customizations with JavaScript that would run in the browser and talk to SharePoint using the vastly improved client-side APIs. The other type of add-in was a provider-hosted add-in, and these types of add-ins involved the developer, also referred to as the provider for hosting their customizations outside of SharePoint, somewhere, we don't know where. This could be a full-blown website or just a small component, and developers were free to use any technology in any platform to implement these add-ins. For instance, they could build an ASP.NET MVC site that was hosted in an on-premises IIS web server or an Azure app, or they could use PHP to create a website that was hosted on a Linux server hosted in Amazon web services. Regardless, it didn't matter what you used to create it, what was used or where it was hosted. The only requirement was that the developer would create a small registration component, just a block of XML, that was installed in the SharePoint site, making SharePoint aware of the fact that this external thing existed. And just like SharePoint hosted add-ins, if these types of add-ins needed to interact with SharePoint, they did it using some of these client-side APIs that Microsoft provided. Now, all wasn't great, but these add-ins, some of them had their own challenges. Whenever an add-in was added to a SharePoint site, SharePoint created a child site where the add-in was installed or provision, and this enabled SharePoint to isolate the add-in from the rest of SharePoint and thus maintain a good security barrier between the customer SharePoint site and the customizations that they were installing on their site. But unfortunately, this wasn't what many of the developers and customers were looking for. In the past with solutions, we could deploy a customization that included a web part, which could be added to a page in a SharePoint site. But the customizations that add-in provided didn't run within SharePoint sites. They ran either in some remote site as in the case of provider-hosted add-ins or in a child site as in the case of a SharePoint-hosted add-in. And in fact, they were surfaced from these child sites within iframes to even facilitate more isolation. But iframes made the page slow because they weren't loading a file. Rather, they issued a full HP request which triggered the full authentication and authorization process before rendering the resulting HTML. And iframes also made it hard to create responsive sites, making mobile sites quite hard if not impossible. This isolation blocked many of the same customizations that we were used to doing with solution-based development. So developers were left with two options. Either continue to use solutions as best they could or come up with another approach. The other approach that developers started to use a lot more to get their jobs done was to inject JavaScript into the pages of SharePoint sites that they wanted to customize. SharePoint included two web parts, the content editor web part and the script editor web part that developers used to inject their customizations into the pages of SharePoint sites. The script editor web part specifically made this really easy. Drop this web part on a page, add some JavaScript to it, and to implement whatever client-side thing that you wanted to implement. And you could call the SharePoint clients at APIs to interact with data within the site. This was helping us solve our problem. It was a great solution and enabled developers to implement their customizations that their customers needed within a hosted environment like SharePoint Online without having to deploy anything to the server. Microsoft was happy, customers were happy. But there was a catch or a few catches to be specific. First of all, these customizations were brittle. And when I say that, I don't mean that they would break easily because of bad coding practices. What I mean is that the deployment story to customize a web part, well, there's really nothing stopping a user with customization rights to put the page in edit mode and modify the JavaScript that you created for them. And for this exact same reason, these customizations were not easily repeatable. You couldn't easily create a customization like this, package it up and deploy it for your customer. Instead, you had to provide them with instructions, things like add the script editor web parts to the page, go into edit mode, copy this code into the web part, change this setting or that setting, save your changes and then test it. And while that works just fine, it's not very repeatable. I mean, it is repeatable, but it's not consistent. And there's also a more significant issue within JavaScript injection approach beyond the deployment and the management story that I just covered. It's one that can be a showstopper. The script editor web part is not marked as quote, safe for scripting. SharePoint has this feature allowing users to create their own sites and this feature is called self-site service, self-service site collections. It includes some of the sites as team sites, my sites and group sites. But unfortunately, these types of sites, they've got a feature enabled called NoScript. This feature removes a specific permission, the add customized pages permission. And the removal of that permission means that the script editor web part is blocked from executing on those sites, thus creating a showstopper for the JavaScript injection approach. Okay, let's stop there. So now you've got, you're all caught up on the history of SharePoint development. And I've explained how SharePoint started with server-side development and over the years moved to not only respond to customer demands, but also to push customizations off the SharePoint server into the browser, into the client. But the options Microsoft has provided us over the years have really not yet met the needs of customers, including SharePoint hosted add-ins and JavaScript injection techniques. So that's why Microsoft introduced a new development and extensibility model for SharePoint. We call that the SharePoint framework. And that's what I'm gonna introduce you to in the next lesson. So I'll see you in the next lesson. Hello and welcome back. In this lesson, I'm gonna introduce you to the SharePoint framework. Now I'm gonna start by walking you through some of the capabilities that Microsoft likes to tout with respect to the SharePoint framework. And I'm gonna share with you what Microsoft says about the SharePoint framework, but I'm gonna add my own thoughts and opinions as well. Not everything that they say is totally legit and should be looked at with your, hey now, that's marketing speak filter at all times. Now the purpose of the SharePoint framework primarily is to make client-side customizations an official development model for SharePoint developers. Developers are able to create client-side customizations that are packaged and deployed to SharePoint sites, just like SharePoint solutions and SharePoint add-ins were in previous versions. These customizations will also have easy access to SharePoint data using APIs included with the SharePoint framework. But this doesn't mean that they'll be limited to accessing just SharePoint data. They're client-side solutions that can use any technology to access other data sources, including the Microsoft Graph or other accessible APIs. Customizations built using the SharePoint framework will run in the current context and unlike their predecessor add-ins that ran within the context of an iframe. Now this means not only will they load faster, but they'll load within the context of the current user and using the current connection in the browser. SharePoint framework customizations are also rendered in the current page DOM, not in an iframe. And that eliminates that requirement, but not the ability to host more involved customizations in another website. Now because the customizations are rendered in the current page and not in an iframe, they'll not have the same baggage associated with them as iframes have. One of the biggest benefits to this is that customizations will be responsive and accessible by nature. And in a significant break from the past, Microsoft has elected to go with a very different development model for SharePoint framework customizations. Traditional and long-time SharePoint developers are used to using tools like Visual Studio to create SharePoint solutions or add-ins. But with the SharePoint framework, Microsoft has elected to embrace and adopt what is commonly referred to as the modern web development stack and tool chain. This approach is really gonna open up the platform to more developers because it isn't limited to just windows. The tools are cross-platform and you can use any text editor that you pervert. Popular open-source tools are used to solve different parts of the tool chain from project scaffolding, building, serving, packaging, all the way up to deploying. I'm gonna get to this development stack in the next chapter in a lot more detail, but just file that away for now. Now when creating customizations in the SharePoint framework, you wanna make sure that you're not excluding your users from using them in legacy SharePoint sites. So another aspect of the SharePoint framework is that customizations that you create will work not only in the current modern pages, but they'll also work in the traditional SharePoint classic web part pages, as well as publishing pages. Well, that's not entirely true, Microsoft. Only some things work in the classic experience. Some extensibility options are only available in the modern experience. I'll address these when we come to them within the course. Now, let's talk about this concept of first party and third party. That's a confusing set of phrases that you might not be familiar with. The term third party refers to people like you and me, people who are creating things to deploy and run within SharePoint. In the past, things like SharePoint add-ins, they were a third party only customization tool. What do I mean by that? Well, in other words, Microsoft didn't create add-ins for SharePoint, they just baked their changes directly into the product. The downside of this is that Microsoft, the provider of the hosting platform and the development model, they weren't using the tools that they gave us to extend the product. So the term first party refers to people like Microsoft. Not only do they create the extensibility model, but they also use that extensibility model to extend SharePoint. And when they wanna create a new component or a customization SharePoint, from this point forward, they're gonna be using the SharePoint framework. So what does that mean to us? Well, they're clearly taking a strong dependency today on their own extensibility model. So they'll be able to leverage the same benefits that it provides that we use in our customizations. But more importantly on the flip side, they'll also be held back by its limitations. And this is good because as they improve the SharePoint framework for their use, we can benefit from it as well. In addition, the SharePoint framework, it's not just limited to SharePoint because since its initial release in 2017, Microsoft has extended support for using it as the development model for creating customizations in Microsoft Teams. Now, this course isn't gonna go into a lot of depth on using SharePoint framework for creating team solutions, but I do have a chapter in the ultimate bundle where I'll show you how to use the SharePoint framework within custom Microsoft Teams apps. Now, let's look at where we've been with the SharePoint framework, where we are and where we're going. Timeline can kind of help here. So at a special event in May of 2016 called the Future of SharePoint, Microsoft announced plans for the SharePoint framework. And then later that year, in the fall of 2016, they shipped a developer preview of the framework that developers could start trying out. And over the next few months, they updated this developer preview with various drops, adding features to complete their plans and responding to feedback from their early adopters. But then in January, 2017, Microsoft shipped a release candidate version of the SharePoint framework. It included quite a few changes that broke a lot of sample projects, but that was really to ensure that developers would be ready for the upcoming release with no more API changes. The final version was rolled out to SharePoint online in Microsoft 365 in the first half of 2017. Now, think of this, final is really a bad name because you should think of it as a generally available milestone instead. As gone are the days of shipping a product and then leaving it alone for a few years. SharePoint online has always had every version of the SharePoint framework deployed, which means that all SharePoint framework projects will run in SharePoint online. Now, since the initial release of the SharePoint framework and for SharePoint online in Microsoft 365, Microsoft has delivered on their commitment to bringing support for the SharePoint framework and their on-premises SharePoint server versions. And specifically, this has been every version since SharePoint server 2016 up to the present day. However, if you're working with SharePoint framework and a SharePoint server on-premises, there'll be a few things that you should be aware of. SharePoint server didn't get support for SharePoint framework until you applied Feature Pack 2 to your on-premises deployment. In addition, SharePoint server 2016 only includes support for the SharePoint framework version 1.1 that was released in June of 2017. And furthermore, Microsoft has no plans to update the SharePoint framework on SharePoint server 2016. So that means you're limited in what you can do to just those capabilities that were supported in the SharePoint framework V1.1. And you can learn more about the support for SharePoint framework in SharePoint server 2016 from the Microsoft documentation at the link that you see here. Now, when Microsoft shipped SharePoint server 2019, they included support for the SharePoint framework as well. However, SharePoint server 2019 only includes the SharePoint framework 1.4.1 released in February of 2018. And this means you're limited in what you can do to just those capabilities supported in the SharePoint framework at the time of that release. And furthermore, like I said, with SharePoint server 2016, Microsoft has no plans to update the SharePoint framework on SharePoint server 2019. So this means you're limited in what you can do to just those capabilities supported in the SharePoint framework V1.4.1. You can learn more about the support for SharePoint framework in SharePoint server 2019 from the Microsoft documentation. Now, this brings up a good point. How am I gonna address the different environments that support SharePoint framework from SharePoint online to the various SharePoint server on-prem versions in this course? Now, when it comes to the developer environment, there are some considerations for you. And the next chapter is gonna address the developer environment. So refer to that chapter for a special discussion related to the developer environment and how to go about creating it and standing it up. But when it comes to the features and capabilities of the SharePoint framework, I'm gonna mention what version of the SharePoint framework this feature was introduced in. And using the information that I just discussed about what SharePoint framework version is supported in the various on-prem deployment options, you can determine if that feature or capability is available in your environment. Okay, so that wraps up my introduction to the SharePoint framework. And in the next lesson, we're gonna take a look at creating our very first SharePoint framework component, a web part in running it in our SharePoint environment. So I'm gonna see you in the next lesson. Hey, welcome back. In this lesson, I wanna show you through a demo what the SharePoint framework experience is all about. In this demo, I'm gonna keep it simple and I'm gonna focus on creating a client-side web part, make one small change to the default one and test it by running it in SharePoint. And then I'm gonna show you what the deployment story looks like by packaging it up, deploying it and adding it to a site. Now, my goal is not to cover all the parts of creating a web part, rather my goal is to give you a quick, high-level, here's what SharePoint framework development is all about kind of experience. And to keep things simple, I'm gonna assume a few things. I'm gonna assume that I've already gone through the next chapter, which gets my environment stood up. So I've already got a SharePoint online developer tenant already set up and configured. I've already set up the tenant's app catalog and I've already installed all the necessary tools on my laptop for SharePoint framework development. In future chapters, I'm gonna walk through each of these assumptions in detail and how you can complete these different prerequisites. For instance, the next chapter is all about getting your developer environment set up. So your focus with this demo is I just want you to see how everything works, how it all comes together. And by the way, you'll see in most of my demos, I use Mac OS as my developer environment. That's just my preference. Everything I'm doing works the same way in Windows. So if you're on a PC, the steps are basically identical. So let's go ahead and get started. So what I'm gonna do is I'm gonna go ahead and jump into SharePoint online first. So let's come over here into Chrome and let's make sure that everything is already set up. So I'm gonna go to portal.office.com to go find my SharePoint site. I'm already logged in. So let's go over here to my SharePoint admin center to find a couple of things. So first of all, in my active sites, I have a site here called my primary dev site. So I'm gonna go there and here's my primary dev site. Now I can also see that the SharePoint online workbench is up and running by going to underscore layout slash workbench.aspx. And that's what we wanna see. I'm getting error here, but that's because I'm not running a local project to see those things, to see everything running. So what I'm gonna do is I'm gonna open up my command prompt. I'm gonna create a project on my local machine. So what we'll do here is I'll jump into my dev folder and I'm gonna create a new folder. So make directory mastering spfx. Actually, let's just call this our hello world because you have to do that for your very first one, right? I mean, I think legally I have to do that. So I'm gonna jump into that folder. I've already got everything installed that I need for doing SharePoint framework development. So I'm gonna say yo at Microsoft slash SharePoint, I'm gonna say skip install. I'll explain what that means in the next chapter. So our SharePoint framework generator, which is think of it as like the tool that helps us get started with creating a new project. That's gonna go ahead and get into fire off. I'm gonna choose all the default options here. So just hello world and I'm just gonna pick everything. It's a web part, it's a standard web part, nothing special. Okay, a lot of different choices there, but we're gonna go through those in a future chapter. So what I'm gonna do is I'm gonna go ahead and launch this guy. So let's go ahead and open him up, code dot. Go ahead and open up and then this is our project. Now let's do this. One of the things I have to do in this project is I have to download all the dependencies and I do that by running npm install. I didn't do that right off the bat because I wanted to open up the project in VS code. So let's go ahead and let this finish and then we'll pick up the demo once this process is finished. So once everything is now ready for our project, what I'm gonna do is I'm gonna run gulp serve and I'm gonna say no browser on the end of this. What that's gonna do is that's gonna compile and build my project and start running it on my local web server, but it's not gonna open up a browser to do any kind of special things with it. Now let's come back over here to our workbench and let's refresh the page. So notice here that when I refresh the page, we got a request that came into our local server and the warning is no longer showing up for the workbench. So what I'm gonna do is I'm gonna hit this little plus and I'm gonna open up the tool bench and I'm gonna look for the web part we just created, which is called Hello World and there it is. Now watch when I select this, watch what happens over in the console. Oh, we can see some stuff got loaded over here from the console, from my local machine. However, we are still in our, up in the SharePoint online environment on the workbench. So here we go, we can see our web part. I can even customize this web part. When I customize it, see some nice cool stuff. You can see like a live update of the text. So we'll say hello, Oytanos. There you go, hello, Oytanos, like that. And save my changes and just close that out, right? So pretty cool. Furthermore, I can also do some other cool stuff with this. If I come back over to my project inside of VS Code, and let's go make another little change to the code here, we'll open this up a little bit more so we can see it. And we have welcome to SharePoint. I'm gonna change that because you're really welcome to my class. I'm gonna say welcome to mastering the SharePoint framework. And I'll save my changes. And when I do that, we can see in our console, some stuff was running off in the background. And what it was doing is it was rebuilding the project on the fly because it saw stuff change. And if I come back over here to the workbench and I refresh the page, it's gonna pick up the latest changes. So we're gonna see welcome to, oh, it looks like welcome to to, I put it in there twice, mastering the SharePoint framework. It's pretty cool. There's more stuff that we can do with this. Let's take a look and see how we can package it up and we can deploy it. So what I'll do is I'm gonna come back over here to my console and I'm gonna stop the web server by just hitting control C a couple of times. And I'm gonna say gulp build to build my project. Well, that was already done. So we should be good. The next step is I have to bundle it up. So I'll say gulp bundle. That takes everything that was just built and sticks it into a nice little bundle. So a lot of JavaScript bundle, CSS files are now gonna be in the bundle as well. That's what webpack is doing. And then finally, I wanna create my SharePoint package. So I'll say gulp package solution. So now everything's been packaged up. If I come over here to my project, I can see that inside of the SharePoint folder, I have this hello world SPPKG. All right, with everything built, let's go ahead and let's deploy our project. So what I'm gonna do is I'm gonna start by going to our app catalog, which is like our special, like think of it as the company store. We'll just think about like that for now. I'm gonna go into my apps for SharePoint folder and wanna upload the project that I've just created. So I'm gonna do that by going by selecting upload and we'll find that project or that package that was just created. And that's inside of a release or SharePoint solution package. There we go. So we'll go ahead and upload that. So you're gonna ask me, are you sure that you trust this? And I said, yes, I do. So I'll say deploy. So now it has now been deployed. What I'm gonna do is go back to my SharePoint site and what I would like to do is I need to install the app that we just created that contains the web part into the site so that I can use it on the site. So I'm gonna do that by going to the site contents page. I'll then go new app and I will go from my SharePoint store or my organization and we can see that there's the one that we just uploaded. So I'll select add. We can say it's now been added successfully so I can go to my site contents page and we should see it listed. There we go. So we can now see that it's finished. So I can go back to the homepage of my site. I'll stick it in edit mode and I will find a place to put that web part which we can see there's a spot right there between the news and the activity. There's our hello world and there we go. We can see there's the web part that we just created. I can then save the page and ta-da. We now have our web part all built. You saw the entire story of building a web part, testing it out, packaging it up and then shipping it out for deployment. That's the entire life cycle of it. So that wraps up my introductory demo into building a web part with the SharePoint framework. You saw how to make some simple changes to the code, get it running on the workbench, deploy it and install it and then add it to the page. Like I said, that's the full life of an SPFX component. It's a full life cycle. So now with that under your belt in the next lesson, I'm gonna explain SharePoint framework, how SharePoint framework development differs from the traditional style of SharePoint development options that we had in the past. This is gonna help those of you with prior SharePoint development experience in building things such as farm or sandbox solutions or add-ins to understand what you are building and why in the SharePoint framework. So, I'll see you in the next lesson. Hello and welcome back. In this lesson, let's look at the different development, customization and extensibility options that we have in SharePoint. And while Microsoft recommends the SharePoint framework for customizing and extending your SharePoint environments, they've not deprecated or removed any of the previous options, at least not yet. But with that being said, some of them aren't available in some environments and they may get deprecated in future environments. Now, let's start by looking at the SharePoint framework just one more time so that we can start drawing comparisons to this. SharePoint framework customizations execute within the client. They're script-based, they're not compiled, so they're all run interpreted in the browser. And thus, they all run in the context of the current page that the user is currently on. Now, this is also the only way to customize SharePoint's modern pages in a supported way, at least. Developers building customizations with SharePoint framework will leverage the modern web development tool chain and development stack. You're also gonna be able to leverage popular open source tools for doing your web development. The SharePoint framework is the extensibility model that has been built for both first party and third parties, meaning that not only do we use it, but Microsoft engineers use it as well to build customizations and components in SharePoint online. And finally, because SharePoint framework-based customizations run in the context of the current page and not some iframe, they are responsive and accessible, and by nature, they're also very mobile-friendly. Customizations that are deployed for use within the SharePoint framework are uploaded to the tenant's app catalog site, making the customizations available across any site within the tenant. So if you're using SharePoint online, you can scope your deployment to just a particular site collection using the site collection app catalog. These deployments are covered in depth in my chapter on deployment to production. Finally, the SharePoint framework is supported in both SharePoint Online and all versions of SharePoint Server, going back to SharePoint Server 2016. However, keep in mind that each on-premises option comes with its own limitations, so refer to the links provided in the lesson notes for details on these on-premises options. Okay, now, let's compare the SharePoint framework to the farm, or fully trusted or highly trusted solutions. Farm solutions are typically comprised of a compiled code, and that runs on the .NET framework. They also consist of some amount of declarative markup, specifically XML, that tells SharePoint under the covers what under what conditions the code should run. And they're deployed using solution packages and features. Now, farm solutions, because they run on the server in the context of the SharePoint farm process, they've got full access to the SharePoint server-side API, and therefore developers can use these types of solutions to do anything supported by the API with custom code. Now, because farm solutions are fully trusted customizations, which means they're highly trusted solutions, they're not permitted in a hosted SharePoint environment, such as SharePoint Online and Microsoft 365. And as such, they're limited to on-premises deployments. And again, due to the server side and full trust nature of these types of customizations, farm solutions, they're almost exclusively built using tools like Visual Studio by developers who are on Windows, because Visual Studio is only really available on Windows or at least the tools for building SharePoint solutions is only available on the Windows version of Visual Studio. Farm solutions are also scoped to the entire farm. Well, then they can be scoped all the way up to the entire SharePoint farm, but depending on the customizations in the farm solution, they can be scoped at the web app level or site collection level or even as granular as just to a specific individual site. Now, farm solutions are at the core of all types of customizations going all the way back to the beginning of SharePoint development, as I talked about already in this starter bundle. And this means that we can use these to create server side web parts, timer jobs, event receivers, feature receivers, and other sorts of controls. And these are all the things that SharePoint framework does not have the ability to create. Now, after farm solutions came sandbox solutions and they were introduced by a SharePoint server by Microsoft and SharePoint server to let developers create server side compiled solutions that run in a hosted environment. Now, initially sandbox solutions like farm solutions, which they're derived from, consisted of both declarative and compiled code. The idea was to give customers a way to extend and customize their site collections without the full trust risks from a farm solution. However, it's really, it changed over time. And it changed in a way that Microsoft removed support for compiled code sandbox solutions and SharePoint aligned in Microsoft 365. I know we've already said this, but I wanna reinforce it. You can still do declarative sandbox solutions in Microsoft 365, you just can't do any managed code in those sandbox solutions. But also, like farm solutions, sandbox solutions are created using the Office and SharePoint developer tools that Microsoft offers as extensions to Visual Studio, which is really the only, is only available to us for developers who are working on Windows. Sandbox solutions are also scoped to the site collection that they're installed and activated from within. And unlike farm solutions, they can be activated at a farm or a web application scope. The widest scope possible for a sandbox solution is the site collection. And this is true for declarative solutions today, as well as when we could still include compiled code while supported in SharePoint online. We used to do a lot more with sandbox solutions when compiled code was supported, but as I've mentioned multiple times, it's not supported anymore, so we can't do that anymore. Therefore, sandbox solutions can only be used today to provision declarative solutions, such as site comms, content types, list templates, and list instances. But we can also use them to provision files like an ASPX or an HTML file, as well as JavaScript, CSS, and images to deploy client-side customizations to a SharePoint site. Now after solutions, as I talked about earlier, came add-ins, and initially these were called apps. Man, the reason why they were renamed from apps to add-ins is a really interesting one, but that's for another time. These are available in two flavors, the SharePoint hosted add-in model and the provider add-in model. For SharePoint hosted add-ins, they run exclusively within a client-side context, and any custom business logic has to be implemented using JavaScript. As the file's deployed to SharePoint, while stored in SharePoint, they're not run on the server. They're rendered on the client, the browser, and then that's where they're gonna run. Now in the case of provider-hosted add-ins, these are more open-ended. The developer, the provider of the add-in, deploys a web application external to SharePoint, and thus they can use any web dev technology that they want at their disposal. They can use any stack or anything. It's all up to them, including the tools. But regardless of the add-in that you create, any time your add-in needs to talk back and communicate with SharePoint, it's gonna do so using one of the client-side APIs that Microsoft has included in SharePoint. That's either the CSOM or a robust REST API. Now when an add-in is manifested within a SharePoint site as a client part, it is done so using an iframe. And this is due to the fact that an add-in execution context is externalized from SharePoint, and it's gonna run in either the SharePoint-hosted web application or within a special SharePoint site that hosts the SharePoint-hosted add-in. Now SharePoint add-ins were typically built by developers using Visual Studio on Windows. And this is because Microsoft only created extensions for Visual Studio with designers for configuring an add-in and creating the add-in package file. Now while provider-hosted add-ins could be authored using any technology for any hosting platform, we saw that most developers using the Microsoft stack and they used to host their provider-hosted add-ins in web apps using iOS web services that were on-premises or in Azure web applications. Now when you as the developer package up your SharePoint add-in, you take the resulting package file and upload it to the SharePoint tenants app catalog. And once that's done, the SharePoint add-in can then be installed within any SharePoint site in that tenant that's associated with that app catalog. And therefore it's scoped to the tenant as far as where it can be used. But the functionality is scoped to the site where it was installed. Now developers can use add-ins to create web parts but not web parts the way we used to do it with solutions. Instead, these are created as web pages that are surfaced within SharePoint using iframes. Developers can also create custom workflows, declarative workflows based on workflow manager and deploy those with add-ins. Now, while the implementation and logic is hosted in a web application external to SharePoint, add-ins can also register remote event receivers. The last type of customization is the JavaScript injection and that's used to customize existing SharePoint sites. Developers can use the continental web part or the script editor web part to get your customizations onto the page as we've already discussed. Now, because of the very nature of JavaScript injection, these customizations are always going to execute within the client-side context. And this means that they leverage the user's context and are rendered in the native page DOM. JavaScript injection involves client-side-based development and these customizations can leverage the client-side API using either the CSOM or the REST API to leverage the SharePoint data and their customizations. JavaScript injection also doesn't involve a specific developer tool. All developers are going to need is a text editor and a way to upload the files to SharePoint and this is typically done using the browser. So developers are free to use any tool that they can use to create their customizations when leveraging JavaScript injection. These customizations are also scoped or added to each SharePoint page on a page-by-page basis and that means that these customizations are scoped to a specific page. Now, because JavaScript injection customizations are done on a manual basis, there's no packaging model. There's no deployment model and there's also no provisioning model that Microsoft provides for these types of customizations. Now, sure, developers can build some sort of a customized solution, but for the most part, these are usually customizations that are implemented on a case-by-case basis and they're usually implemented manually. Okay, so in this lesson, we looked at the previous options for SharePoint customization and extensibility and I compared them to what we can do in the SharePoint framework. So by now, you should have an idea of where the SharePoint framework fits, but also just as importantly where it doesn't fit. So in the next lesson, I'm gonna wrap up this chapter by pointing you to different resources that you can use to ask questions and learn more about the SharePoint framework from the community. So I'm gonna see you in the next lesson. Hello and welcome back. Now, in this lesson, I wanna share with you some resources where you can learn more from the community and places where you can get your questions, where you can ask questions when you get stumped. Now, this course is gonna cover everything that you need to know to be productive and master the SharePoint framework, but in the interest of full transparency, you really should have a few more resources in your back pocket. But as students of this course, keep in mind that you can always drop a comment in the area below the videos in every lesson page. And also if you're a student of the ultimate bundle, you've got access to the student-only mastermind group and our regularly scheduled office hour sessions. Now, let's start by identifying the Microsoft Run communities and resources. Your first bookmark should be the SharePoint framework developer documentation. That's where you're gonna find all the official product and platform documentation from Microsoft. The next two resources from Microsoft are that you should follow that are related to the SharePoint framework are the two primary organizations for SharePoint and the Patterns and Practices Group. Both of these contain tons of samples and reference projects and resources, guidance and tools and SDKs, you name it. And these are all available on GitHub. Now, I do wanna call out a specific repository in the SharePoint organization, the SP Dev Docs repo on GitHub. Now, this repo contains all the SharePoint developer documentation that's published on the docs.microsoft.com site that I referenced above, but it also contains an issues list. And this is where Microsoft has told customers where that they should post their issues and bugs related to the developer platform or related to the SharePoint framework documentation. So, where are you supposed to go to ask questions? Well, like any technology, it really depends. I'd suggest that you look at a couple of different options, try out a few and see what works best for you and where you get the best results. Now, Microsoft is gonna tell you to use the SP Dev Docs issue list that I mentioned above, but I think it's questionable as a good option. Many questions are left unanswered in this community. Another option is the SharePoint developer discussion space on the tech community site that is also run by Microsoft. There's a good mix of community discussions and announcements that are made in this discussion space. So, that covers all of the Microsoft run resources. Now, let me point to some of the resources that are run by the community or third parties. Now, this is not gonna be an exhaustive list by any stretch of the imagination. Like JavaScript frameworks or any cryptocurrency coins, every time you turn around, it feels like there's another one of these that's popped up. So, I'm gonna call out some of the highlights and the ones that I think are pretty good that you should check out and where I have the most success. Some of these are run by the community while others are managed by companies for their benefit. Now, it really should come as no surprise that I'm gonna mention Stack Overflow. It's quite popular and quite possibly the standard for forums as a place to ask technical questions. And one of the reasons I like it is because it's really just a big bucket where you drop a question in and then you apply relevant tags to them. This means you don't have to go through the mental gymnastics of trying to figure out which bucket does this question belong to. It's far too rare these days that a problem we're working with can only be put in a single category. Now, when it comes to the SharePoint or the SharePoint framework, I recommend you use the tags on your questions for either SharePoint or the SharePoint framework. If it's a SharePoint framework one, would you just need the SharePoint framework tag? Use those for your posts that you put on Stack Overflow and then add any additional tags for anything that's relevant. Furthermore, check out the dedicated SharePoint Stack Exchange site. It works the same way, but it's just for SharePoint questions. I'll admit that I've never been completely clear on exactly why you'd use one or the other. But now for the rest of these things that I'm gonna go over, you're just gonna have to find out what works best for you because with so many options, look, here's how I'd approach it. Find a platform or platforms that you're most comfortable with and then find a form or a community or whatever that platform calls them and then evaluate if that's a good place to ask questions. What I do is I look at the number of people who have joined the sub as well as how active it is by checking the timestamp on all the latest posts. When looking for a community or a forum to ask questions, you wanna see lots of people and lots of activity. I call that like the bilateral activity. We wanna see a lot of people asking questions and I wanna see a lot of people answering or engaging with the people that are asking questions. And furthermore, I also like to look at the reliability of it. So how long has it been around? How popular is it? How often are people using it? How often are they getting good responses? I also think that you should look at who the group's owners or admins or moderators are. And that's sort of like the old saying, follow the money. Some people have very specific reasons for setting up these groups. So I'm sure you've heard of something called Facebook. Many companies and organizations and users have created groups dedicated to having conversations, asking questions and sharing news related to SharePoint development. There's so many groups on Facebook that I don't wanna recommend anything because I'm surely gonna leave something off. Everything that I just said about Facebook, that's also true for LinkedIn as well. Plenty of groups, lots of engagement, very popular. The one thing I just say about Facebook and LinkedIn is like I just mentioned a second ago to look who runs the different groups that you're looking at. In other words, follow the money. Sometimes a company's gonna stand these up and they do it to get a lot of people in these different groups. And then they can use that usually to target ads to all those people that are on those groups. That's true for both Facebook and LinkedIn. I'm not saying that's a bad thing. I'm just saying it's something that you should just be aware of because maybe that's something that you're not comfortable with. Me personally, I've got no problem with it except for the fact when I see companies stand up their own when there's already very existing established ones, that's when I start to kinda look at it and go, well, what's wrong with this other one that's already there? Sounds like you're just trying to do this for an ad play and you're not really there to help the community. That I don't think is very cool. Now, another option we have here is Reddit. This is called the front page of the internet and you're gonna find various forums on Reddit. For those not familiar with Reddit, it's simply a collection of forums where people post threads. These different forums, they're called subreddits or subs and you commonly see them with a reference starting with a slash R prefix. That's because that's how the URL is set up. Two really popular ones that are related to SharePoint is the slash R SharePoint subreddit and the SharePoint dev subreddit. There's other ones as well, but those are the two big ones that I would look at. Now, another option that's pretty popular these days is Discord. It's a great place to have discussions and it differs from forums like Stack Overflow and Reddit and that it's more of like a near real-time chat and less about like leaving questions and getting answers. Not as real-time as something like Twitter, but well, just check it out for yourself. Now, I'm gonna update the lesson notes with any Discord servers that are dedicated to SharePoint development, but for right now, I'm just gonna leave it as those two. Now, don't forget, if you've subscribed to the Ultimate Bundle of this course, you've got access to the Mastermind group in the regular office hours. I host the office hours and I send invites out at least a week or two prior to each meeting and the Mastermind group, that's implemented as a private Facebook group. So when you enroll in the course, make sure you answer the questions when requesting access to the group to ensure that we can verify that you're a student of the course. You can get a link for that group from the header part of the Ultimate Bundle. It's not only in the emails that you receive when you subscribe to the Ultimate Bundle, but it's also linked in the heading on the index page for all the chapters once you've logged in and access your Ultimate Bundle. When you make sure that you put the email address in when you applied, become a member of that group, that you've used to register for the course, because that's how I ensure that you're a student of the course and there's not somebody else that is not a student of the course that's getting access to it because this is really a benefit for you guys. Okay, so that wraps up my introduction to the SharePoint Framework chapter. Let's take a look at everything that we've covered throughout this chapter. I started with an introduction to the SharePoint Framework. We first took a look at the history of SharePoint development. We looked at SharePoint Server 2003, 2007, 2010, 2013, all the way up to today in SharePoint Online and the latest SharePoint Server on-premises options. We also looked at the different development and extensibility options that Microsoft has provided to us as developers along the way from farm solutions and sandbox solutions to both SharePoint-hosted add-ins, provider-hosted add-ins, all the way up to the JavaScript injection and the SharePoint Framework that we have today. And by looking at this history, we were able to get a bit of a picture on the motivation and the reasons for the SharePoint Framework and why Microsoft created it. This helped us understand it in a little more context. Finally, we looked at the different resources available to us in addition to this course. Many of them from Microsoft, including documentation samples, places to ask questions and submit suggestions, not to mention other resources available to subscribers of the ultimate bundle in this course. We also looked at all the community different options. And this chapter, or this concludes this chapter, but there's one more chapter in this free starter bundle and the next chapter, I'm gonna talk to you and show you how to get your development environment configured to start building and testing SharePoint components for the SharePoint Framework. So I hope that you'll continue your learning journey with me and join me in the next chapter. Thanks for watching. And if you enjoyed this video, please click that thumbs up and the big red subscribe button below to get more of my SharePoint Framework educational content as I publish it. And this video is one of the chapters from the free starter bundle of my Mastering the SharePoint Framework course by Vojtanos. And you can find the other free videos from the starter bundle that are listed in the description below. That course contains over 35 hours of in-depth explanation and instructor led demos, teaching you everything about the SharePoint Framework to become a master. I offer this course in three different bundles, the starter bundle that this video was part of, as well as the fundamentals bundle and the ultimate bundle. Each of these bundles contains more content than the previous bundle and some additional resources like mastermind groups and regularly scheduled office hours. You can learn more about the course on our site that I've linked here or by clicking the link in the description below the video.