is a blog written by Josh Carlisle based out of Raleigh North Carolina where I explore, Share, and sometimes abuse the modern software development landscape. 


Getting Started With Modern SharePoint Development

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.

Traditional SharePoint development that has made heavy use of full trust server side solutions built on top of and the SharePoint server side object model have been steadily falling out of favor for client side development that makes more use of various JavaScript frameworks in concert with SharePoint REST services and the JavaScript Object Model (JSOM). Part of this has been out of necessity with the growing prevalence of Office 365 which does not allow developers to deploy custom code to SharePoint. It also follows a general industry trend for client side development and the user experience that comes along with it.  Client side development however, comes with its own set of challenges.  The various tools and frameworks that have been part of many traditional front-web developers for years often seem very foreign to many server-side SharePoint developers. To add insult many of the tools don't integrate as well with Visual Studio, our traditional development platform of choice. 

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, 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.

Languages: JavaScript

There is no way around it - you will need to become proficient at JavaScript first and foremost. JavaScript will be the foundation for many of your client based solutions and possibly even some of your server solutions as well through Node.js which I cover later in this post as well.  There are countless resources online for learning JavaScript so it's beyond the scope of this post to cover JavaScript but it's the place you should start after downloading Visual Studio Code.

Ensure you are comfortable with the built in methods and standard data types, functions, closures, Callbacks, and promises just to name a few. You should have a solid understanding of how to make server REST calls. As beneficial as frameworks can be there will be often times that using a framework is an overkill for your solution and you cannot go wrong with having a solid foundation with vanilla javascript. 

Language: TypeScript

Typescript is a superset of JavaScript that compiles into standard JavaScript. With typescript you gain access to many of the benefits of modern strongly types programming languages.  Some see Typescript as a short term crutch to help .net developers transition to the loosely typed and dynamic nature of JavaScript but I would argue it opens the door to all development benefits that modern languages and their compilers provide.

Like many programming languages JavaScript has been changing and evolving over the years. New features and language constructs become available bringing enhancements to the core language.  Those language enhancements go through additional industry organizations for ratification and eventually the specification is included in various browsers - all at the release schedule and whims of the various browser vendors. If this sounds like a long pipeline it is! 

This is where tools such as Typescript come into play. They allow us to get access to the latest JavaScript language enhancements today! This is accomplished through a process called transpiling. Typescript is transpiled back down to a desired version of JavaScript that is more widely supported by browsers so you can still maintain broad support for various browsers within your application.  For traditional c# developers this means you have access to many of the same language constructs like classes, interfaces, strong types, async\await just to name a few.  Just like .net is compiled before running Typescript is transpiled before execution or more commonly automatically in the background as you're working.  Visual Studio Code has built in support for Typescript along with various other tools like Gulp and Webpack that can manage the process for you as well.

Despite the fact that it's transpiled back down to standard JavaScript there are tangible benefits during the development cycle with arguably fewer unexpected runtime errors from unexpected typing issues. Typescript will also feel more comfortable for developers coming from languages such as c#.  It's important to understand however that learning typescript does not negate your need to understand the underlying core JavaScript framework but it may improve your development experience and the potential stability of your application.

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.

UI Frameworks

JavaScript frameworks and libraries will play an important role in your client side development efforts. To be clear I'm referring to frameworks and libraries that effect the overall application architecture. The approach you take for your user interface, how you handle data binding, how you manage your application logic not simply the library you may use for example to render charts within your application. This decision is akin to deciding whether to use ASP.NET Forms or ASP.NET MVC for your traditional .net web application.

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?

I've worked with many different JavaScript frameworks over the early years of ajax (I'm even guilty of using update panels a time or two…shudder!!.. ) and pure jquery implementations to more recent years knockout, handlebars, backbone, ember, angular, react, and most recently angular 2.  Putting all my cards on the table I've only used knockout, angular 1\2, and react in production level applications - the others have been more small scale efforts and experiments but I've felt like I've gotten a good feel for the overall landscape. 

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.

Tools: webpack

Webpack at its core is a module bundler.  Module Bundlers are meant to handle the complexity of dependency management across various JavaScript files and libraries. These files are then bundled together to reduce overall page load time and eliminate unused code. Other common client side bundlers include RequireJS and SystemJS.  What makes Webpack more is the ability to process additional file types through the use of custom loaders. These loaders can manage other file types such as css and html files. In the case of CSS and Javascript the files can then be further optimized and minified.  Loaders can compile typescript and convert images to base64.   In the past you may have had to use multiple tools such as Grunt or Gulp for custom tasks in addition to a module bundler can now be achieved with a single tool.  Like many development tools Webpack requires Node.js and is configured through JavaScript configuration files as part of your build process.

Tools: Node.js

Node.js is a JavaScript runtime environment built on Chrome's V8 JavaScript engine.  Not only is it the foundation for many popular development tools such as webpack and gulp it is also rapidly growing in popularity as an application host. Many application services that you may have written using solutions such as the ASP.NET Web API can also be written in JavaScript (or typescript!) with Node.JS. There is something to be said about the power of developing client side and server side solutions with the same language and toolset - that of JavaScript.

The developer tools however are where most developers will turn to make use of Node.js. Node.js uses a package manager called NPM that has thousands of JavaScript based packages. All of your development dependencies from your tools such as webpack and gulp to the libraries your application requires such as jquery and angular.   All can be managed from a single JSON configuration file.   For those familiar with Nuget in Visual Studio this falls into the same family.



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.

  • Gulp - Gulp is a task runner that in many ways is comparable to MSBuild. It is based on Node.js so Gulp tasks are written in JavaScript.  Many of the tasks that are typical for Gulp are already managed through webpack but the SharePoint framework has some specific build and packaging tasks used for solutions.
  • 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.

Parting Suggestions

I advise not trying to take on all of these at once. Instead start with downloading Visual Studio Code. Then start with your core Javascript and TypeScript concepts.  Don't get pulled into too much module and packaging when getting started with TypeScript. You can simply compile your typescript from the command line while you're getting started. Typescript will lead a natural transition into learning webpack. All of this should lead up to working with the frameworks which with the foundation you've built should allow you to concentrate entirely on the frameworks and not getting caught up or confused in the tools and packaging that come along with them.  


Azure Functions & Office 365 - Match Made in Heaven

Azure Functions & Office 365 - Match Made in Heaven