Microsoft recently announced the general availability of the SharePoint Framework, a new development model for the creation of custom solutions within Office 365. The SharePoint Framework, also known as “SPFx”, provides customers with a way to extend the platform for Intranet and collaboration scenarios with a “pages and parts” model that is lightweight and easily configurable. As with any new model, developers will need to learn a new way of doing things, but SPFx has some specific requirements that may prove challenging for those who have been working with SharePoint for any length of time as well as those who are new to the platform. Before getting started, it is important to learn what skills are necessary, which tools are required, and how to configure an environment to begin creating SPFx solutions.
SharePoint development has always been a balancing act between the extensibility options of the platform and the tools required to effectively take advantage of those options. In the early days of 2003 and 2007 there were a mixture of manual procedures and community-provided solutions that more or less got the job done, but certainly did not provide a streamlined build-and-deploy experience. Things changed dramatically in 2010 when the toolset was integrated into Visual Studio, which made a great deal of sense as all SharePoint projects were essentially ASP.NET solutions comprised of compiled code, markup and XML. Having everything together in a single IDE made it much easier to manage and maintain complex solutions.
With the introduction of the add-in framework in 2013, the reliance on a specific development environment was reduced, as solutions could be built on any platform; although in reality the vast majority were still created and deployed from Visual Studio using the provided Office developer tools. SPFx changes all that, eliminating the need for a commercial IDE and instead utilizing open-source tools for code generation, packaging and deployment. This is partly in response to current trends in the wider web development community, but also reflects differing priorities between the SharePoint and Visual Studio teams, with the former fully focused on cloud-first technologies and the latter required to support a much wider array of legacy and enterprise scenarios.
The final portion of the toolchain, and admittedly the most confusing for existing SharePoint developers, is the set of components required to package and deploy solutions so they can be tested within the workbench. For better or worse, Visual Studio obfuscates much of the plumbing required to actually build a WSP package or app file, making it seem much simpler than it actually is (for those who were around in the old days and remember makecab.exe and diamond directive files, this is a welcome improvement). Unfortunately, the open source toolset is not as streamlined, so there will be some adjustment to tools like Gulp (a task runner and build generator similar to MSBuild), Node Packaging Manager (NPM), which handles the vast array of project dependencies, and the project artifacts required to get everything working the right order.
Assuming setup happens on a clean machine with no previous versions of the tools, following the Microsoft documentation should be a fairly straightforward process; however, if things go awry or if previous versions of any tools already exist, sorting out the dependency conflicts can be a time-consuming and frustrating task. This, unfortunately, is the state of things for many non-Microsoft developers and something the SharePoint development community will simply have to accept until such a time as the toolset changes or new processes become available.
Once the environment is in a functional state, the Yeoman generator can be launched and a new project created. Developers should ensure they have plenty of disk space for building and testing SPFx solutions as the toolset creates a full copy of everything the project depends upon in the target directory. This can result in hundreds of megabytes for even the simplest of “Hello, world!” web parts. Fortunately, this is only a development issue, similar to how Visual Studio installs gigabytes of stuff that few people actually ever use, as the final package that gets deployed to the CDN is quite small.
Testing in the Workbench is a nice feature that removes the need to constantly redeploy everything to SharePoint for iterative debugging, although once the API’s are invoked for data exchange it is better to have the web part on an actual SharePoint page. This is where additional tools like Fiddler, Wireshark and browser-based development utilities can aid in the debugging process. For source control, Git (and the public/private hosted repositories on GitHub) is the tool of choice for most web developers. There are client tools (and even a GUI for Windows) that can be installed on every platform and some IDE’s also offer direct Git integration. For those running Visual Studio on Windows to manage project structure and code editing, TFS remains a viable option with or without Git integration.
As the latest and most cloud-focused of the various development models, the SharePoint Framework will be receiving a lot of attention going forward. Developers who wish to adopt SPFx as part of their overall extensibility strategy for SharePoint will need to learn some new skills, adapt to a different set of tools, and ensure they have a properly configured environment to take advantage of the new model. Although it may initially create some challenges as the community adapts to a new way of doing things, in the long run the greater the adoption the more likely the possibility of future improvements and the more resources Microsoft can dedicate to providing enhancements.
Eric Shupps is a SharePoint Server MVP, and the founder and president of BinaryWave, a global provider of SharePoint managed services. He will be presenting developer-focused sessions at SPTechCon Austin, April 2-5.