Getting Started With Modern SharePoint Development
"If you don't hate SharePoint development you're not doing SharePoint development." … said everyone
This phrase was on a t-shirt back at the first and only Office Developer Conference (ODC) back in 2008. I can only guess it was meant to bring attention to the plight of the SharePoint development community at the time. Having worked with SharePoint since 2004 and with no real development tools and little or no documentation it rang a cord with me at the time. Unfortunately for many it still rings true for SharePoint developers in 2017. Despite many improvements over the years SharePoint development still remains a source of frustrations for its legions of developers. It should come as no surprise that many of its developers who have toiled over the years to get to a level of proficiency are now feeling left behind as a different model for development, that of client side development, starts to emerge as the new defacto standard. In one of the ultimate ironies developers who have been accused of not being "real" developers, spending most of their time in Content Editor Webparts and SharePoint designer writing scripts in many ways may find themselves better equipped for the coming transition.
Some may see this new modern development shift in a negative light. Yet another methodology to learn. Yet another investment. I would argue however that the failures of previous development experiences were caused by the inability to bring the SharePoint development experience on par with that of standard web development. By embracing standard development methodologies SharePoint no longer has to raise that bar but instead simply requires improved integration and best practices. To be fair, traditional SharePoint development is not going anywhere. For on-premise this model will likely be supported as long as there is an on-premise version of SharePoint but the future is here now and it's time to get ready.
Code Editing: Visual Studio Code
For many developers their code editor of choice plays a major role in their development success. There is little worse than experiencing a lot of friction with your development tools, it just makes everything harder and that much slower. Traditionally the editor of choice, at least on windows, has been Visual Studio. Although the latest releases of Visual Studio 2015has improved its support for various modern tools such as various package managers and task runners it's generally been slow to respond and for many developers it has the bolted on feel. Some actions are triggered during builds, some are run through task runners, some have obvious configuration while others are hidden behind custom dialogs and wizards. Some functionality is built from community projects while some has been added with service packs. I still prefer Visual Studio for what it was built for, traditional asp.net, Web API, MVC, Windows - essentially .net development but when it comes to front-end UI development I now prefer Visual Studio Code, Microsoft's free open source code editor.
TIP: Visual Studio 2017 has a release candidate. If you're organization has standardized around Visual Studio I would encourage you to explore what new features are available in Visual Studio 2017 and see if the client side development experience improves.
Visual Studio Code has many of the popular features developers would expect including IntelliSense, Debugging Support, Extensions Support, built in support for Git, advanced editing support like peaking and code snippets along with support for a huge amount of languages. Visual Studio Code has more in common with editors such as Sublime and Atom then Visual Studio proper. In many ways it's a very lightweight editor but with optional access to very powerful features and extensions. Whereas Visual Studio has release schedules measured in months if not years, updates including new features and bug fixes are released for Visual Studio code monthly. The development experience is a departure from what you would expect with Visual Studio so it does take some getting used to but most will find the streamlined and simplified interface yet access to powerful development features a joy to work with once you get used to it.
This may seem like a strange place to start but beyond the fact that it's a great code editor , you will find many of the tutorials, code examples, and communities that you will visit on your journey have all embraced Visual Studio Code. Having attempted to apply tutorials to Visual Studio that were done in Visual Studio Code I can tell you that it's an unneeded learning distraction. Lastly a clean break from Visual Studio might facilitate the conceptual shift in development from server side to client side development.
Typescript is not the only player on the field though. Additional tools such as Babble and Coffee Script are a popular choice as well. My recommendation for Typescript comes from not only it's growing popularity but it's support from industry leaders such as Microsoft and Google. In fact many modern libraries and frameworks such as Angular2 and the popular Office UI Fabric React components have been built from the ground up using Typescript. Typescript is quickly becoming an industry leader.
Choose poorly and you may get more overhead and little benefit from the framework. Choose one that ultimately becomes unpopular and you risk having to support premature legacy code or incur expensive migration and update costs. The last several years has seen an absolute flurry of frameworks come and go. To make matters more difficult some don't end cleanly and instead stutter and start as their popularity waxes and wanes within the community. To say the scene is a bit volatile would be an understatement! This cycle does show some signs of slowing yet the decisions still remain difficult. With all of these challenges where do you place your investment where it's least likely to fail?
In the end I find my two recommendations continuing to be both Angular 2 and React - each when it makes sense. Attempting to compare and contrast the two is much like comparing apples to oranges. Instead I'll explain the nitch that I have found success with for each.
UI Frameworks: React
The line of framework vs library blurs a bit when it comes to React. Since its focus is the View most refer to it as a library since you often need other libraries to manage many other common application tasks within React. For me the sweet spot for React has been smaller components that have a strong display component. React seems a very good fit for the new SharePoint Development Framework which is essentially SharePoint's new webpart framework (although it may become more in the future). Additionally the SharePoint team has taken great interest in the framework with supported open source projects such as the Office UI Fabric React Components and development of official Office 365 applications such as Delve being built on React. In general React is a slimmer less prescriptive framework but requires additional libraries for common things like routing, web service calls, and more advanced forms handling. For Single Page Applications (SPA) or larger applications in general I prefer the additional feature set that Angular 2 providers.
UI Frameworks: Angular 2
Angular in many ways broke new ground by combining several emerging concepts at the time around components, data binding, and dependency injection together for arguably one of the most popular frameworks to date. With it though came complexity, a steep learning curve, and under some scenarios performance limitations. Angular 2 worked to increase performance (by all accounts successfully) and make implementation choices more clear and standard - some would say a more prescribed architecture. Larger web applications benefit from the consistency provided from the framework with the different components being well vetted and tested.
The pain point for Angular 2 has been its radical departure from previous 1.x frameworks. For those still using Angular 1.X it is highly suggested to use the latest 1.5 component architecture which more closely aligns with Angular 2 making migration less of issue. Although in development for years Angular 2 is relatively new but quickly gaining in popularity. Even the Azure portal team has chosen Angular 2 to develop some of its latest modules including the Azure Functions dashboard (most of the original azure portal is written in Knockout\TypeScript).
NOTE: There is currently an issue with Angular 2 with the SharePoint Framework. Multiple Angular 2 components are not currently supported on a single page. This is not a SharePoint Framework issue but an issue with how Angular 2 is optimized and loaded for page performance. If you want to use Angular with the SharePoint Framework it is suggested to use Angular 1.5 until this issue is resolved. There are members of the SharePoint developer community actively working with the Angular 2 team to remove this limitation.
Extra Credit - Additional SharePoint Framework Tools
A lot of attention has been given lately to the SharePoint Framework which makes additional tools suggestions. Although still in preview and only available in Office 365 (and potentially future Feature Packs for SharePoint 2016) it's a likely preview of things to come. None of these tools are technically required for the SharePoint framework but they do make the process of creating, building, and packaging SharePoint Framework Solutions easier.
- Yeoman - Yeoman created project templates. In many ways it accomplishes the same steps that the New Project wizard in Visual Studio does. It's a good tool to use and can provide some consistency to your projects.
- Git - Git is a popular source code repository. Both Visual Studio and Visual Studio Code have GIT integration but only Visual Studio has other types of integration like TFS and VSO. Git also integrates very tightly with many Azure deployment schemes.