I’ve seen the future of SharePoint development and it’s decidedly cloudy. And that’s a good thing, no, that’s a great thing for the health of the SharePoint developer community.

A few months back I was fortunate enough to be invited to attend a SharePoint Dev Kitchen on the Microsoft campus in Redmond, Washington. This was a fantastic three day event to get some developers hands on with the new development approach that the SharePoint engineering team have been working hard on. First I have to thank Dan Kogan, Adam Harmetz and the rest of the team for putting on such a great event. This was probably one of the best technical events I’ve ever attended.

Over three days we got to explore a new way of building WebParts, custom lists and applications on SharePoint. All while the engineering team looked on and worked with us when we ran into issues. The engineers also took the time to understand why we were taking particular approaches and discuss what we perceived as the necessary for a successful v1 of this new development approach.

So, about this new way of developing against SharePoint. If you didn’t catch the #FutureofSharePoint event and haven’t picked up on the not so subtle hints that have been coming from those in the know it’s a JavaScript centred way of enhancing SharePoint. Before you freak out too much, the CSOM APIs are not going away, you can still write Full Trust Code, you can still make use of the Add-In model, all that great guidance in the PnP is still incredibly valid, this is just another tool in the toolbox.

But you know what? I think that it’s going to be a much better option in many cases. For example, in the case of WebParts, under the Add-In model those are actually IFrames to some code either hosted in another Site Collection or on a whole other server depending on the Add-In flavor you’re using. In the new model, well, that code is just another script in the actual page you inserted that WebPart, which comes with the benefit of easy access to any of the JSOM APIs and REST endpoints for the site.

What we got to play with was a custom Yeoman Generator which created one of three project types: WebPart, Custom List or Custom Application. For those folks coming from a pure .NET background the best way to think of this is a command line too that performs the same role as the multiple steps you walk through in Visual Studio when you hit File > New Project and walk through the steps to set up a SharePoint or Office Add-In. This sets up a project that uses TypeScript as the language of choice and a Gulp task runner to help with your dev workflow. Most importantly the tooling doesn’t force you to use any particular front end framework or libraries to build your WebParts or Applications. The engineering team showed us examples using React but you can use AngularJS if that’s your preference, heck I’d be willing to bet using Aurelia shouldn’t be too hard either.

From my perspective this strategy of providing developers working against SharePoint with a means of leveraging all that modern web development has to offer is a great thing. Offering developers more choice about the languages, tooling, and frameworks that they are able to use is a healthy thing. On the note of choice, just because the version of the tooling I played with set you up with a TypeScript project doesn’t mean that you can’t use ES6 or plain old JavaScript either, due to the extensible nature of Gulp you can change out the parts of the default build set up that you don’t want for options you do. This model of development is incredibly open and allows you use pretty much any JavaScript tools or libraries you want.

You’ll note that I’m calling the future cloudy, that’s because all of the new innovations are going to land in SharePoint Online / Office 365 first. For me as a developer that means that’s where I want to be working by preference. I want the shiny new toys as soon as possible with all the challenges and joy that comes with that decision. And if your client hasn’t got a compelling reason to keep their SharePoint instances On-Premises then they should probably be looking a moving into Office 365 to get all the benefits of the new engineering effort and new features sooner rather than later, or in the case of some features, never.

This change is a huge shake up for developers in SharePointlandia, for too long SharePoint developers have been stuck working with the previous version of the .NET toolset, now they have a chance to step up an move to the cutting edge albeit with a slightly different set of tools to what they have traditionally been used to. Use this opportunity to embrace the change, learn new skills and discover the joy of abandoning Visual Studio.