With the push to move away from On-Premise SharePoint environments in favor of the Office 365 SharePoint environment, Microsoft has drastically changed the landscape of SharePoint development. I’ve been a SharePoint developer since 2007 and making the jump to SharePoint Online has been the most jarring change yet. Of course when SharePoint Online was first announced and as features have been introduced, I’ve played around with them in a strictly “Hello World” capacity, but as any developer will tell you, creating a “Hello World” project for play purposes is drastically different from actually creating a real-world-use project.
I recently got to create my first “real” SharePoint Framework Web Part and here are my thoughts, as someone coming from over 10 years of On-Premise SharePoint development.
- Right off the bat, I love the SPFx workbench. Previously with On-Premise development, you would have to compile and deploy your Web Part (which was a nightmare before SharePoint 2010), then attach your debugger to the browser process in order to debug. You also had to make sure your user account has the proper permissions in the SharePoint environment in order to deploy in the first place. This process would usually take a few minutes at best, which was especially annoying when you find out you had a small typo in your code or something and would have to wait another few minutes just to get it out to your development environment. With SPFx, you just run your “gulp serve” command and you immediately have a locally-hosted version of your web part to play around with and develop against (and it would even auto-refresh as you make changes to your source files!). Microsoft even went the extra mile to give us a workbench on every SharePoint Online site that doesn’t require deploying and installing the SPFx web part – it reads your source files from your localhost as long as “gulp serve” is running, and even runs in the context of your SharePoint Online site! Meaning you can test with real SharePoint data. The workbench is just so much easier to develop against than having to run a gamut every time you want to make a change to a web part.
- The SPFx tooling really doesn’t feel like it’s feature complete yet, despite SPFx being available for general use. Coming from heavy Angular CLI usage, I feel a bit hamstrung using the few gulp operations available out of the box. I know you can write your own gulp operations, but when the Angular CLI comes with so many pre-configured commands, it really feels like “why should I have to do this?”. Heck, even when you generate an SPFx web part project using Yeoman, the output README file has a bunch of TODO placeholders!
- Setting up the App Site/Catalog and (if necessary) CDN is a hassle. I know it’s a one-time thing, and once it’s setup you just forget about it, but it’s still annoying. With On-Premise you just needed to make sure you had Site Collection Admin privileges and write access to the SharePoint configuration database, and you could deploy farm solutions to your heart content. Under this new paradigm, all SPFx projects get uploaded to a special App Site that’s setup by your administrator and (if desires), your projects could need to be approved before accessible. I understand the need for security, but this reflection piece isn’t concerned with security and for my development purposes, it’s not like some administrator (me) is going to reject my project anyway. As far as the CDN goes, the SPFx tutorial from Microsoft walks the user through setting up a CDN site to host your SPFx web part’s assets (js, css, images, etc), with a small note at the bottom of that particular section mentioning that you don’t have to use a CDN, and could just host your assets from the App site. So not even really necessary unless you have need for a CDN.
- In SharePoint On-Premise development, you had a solution that could divide your custom code pieces into “features”, which could target an entire farm, site collection, or just an individual site. The end-user could then turn features on/off as they desired. With SPFx, it seems that it’s an all-or-nothing situation, with no concept of features to sub-divide your code based on your site’s needs. If you want the web part in your SPFx project, you’re going to get everything else that’s in that same project.
- Do you want to do something “outside the box”? Good luck! SPFx is still pretty new so it’s hard to find good resources out there that may help in accomplishing exactly what you want to do. For example, I wanted to integrate Vue.js into my SPFx web part (which there were some helpful resources to do just that), but then I also wanted to have my HTML in a separate file from my Typescript. This resulted in a “carriage before the horse” situation where Vue.js would instantiate before the HTML is loaded into the DOM, which of course resulted in no DOM elements to Vue to bind to. I basically had to inject my HTML into an empty DOM element that my Vue was bound to (meaning I still have a little HTML in my Typescript file).
- I hope you get familiar fast with config.json, package-solution.json and all the other JSON files that are used as part of the overhead of an SPFx project. Want to change your project name? You need to edit the package-solution.json file. Maybe you don’t like what your web part is called…dive into the web-part.manifest.json file to change that. This isn’t a dig at SPFx specifically because these JSON files are very reminiscent of all the XML configuration files we had with On-Premise solutions. But at least with our On-Premise solutions we had Visual Studio property panes to make simpler configuration edits to our XML – with SPFx, there’s really no alternative to digging into JSON files to change overhead “stuff.”
So I’ve only been working with SharePoint Framework in a “real” capacity for about 2 weeks, but these are my takeaways so far. I’ll still be at it, and there’s a lot more for me to get into (How do I do site-wide script injection? Can we replicate Custom Action functionality? Modify the navigation?) but overall, I’m enjoying my foray into SPFx. And I freely admit that some of my more negative points above may be a result of being used to a decade of On-Premise development plus just not being as familiar with SPFx yet.
Overall, in keeping with Microsoft design, if you want to do custom Web Parts (and other functionality) in SharePoint Online, you’re going to have to get used to SPFx. At least this time it seems the only option available isn’t a nightmare to work with (cough cough SharePoint Designer cough).