In the past few years we have seen tectonic changes in the SharePoint developer’s land. Shifting from the server side to the client side, demise of the feature framework, the rise and the decline of the Apps (AddIns!), and the dust settling with SharePoint Framework. Usage statistics of SPFx are nothing but impressive, and SharePoint developers kind of found their feet again, enthusiasm is noticeable everywhere. What can you tell to SharePoint developers, what they need to learn, what they need to pay attention to?

SharePoint Framework is really the key to concentrate and learn for the future. What’s great about it as well is that even though there is a clear learning curve, after you have climbed that, you are then generic web developer using industry standard techniques. This is a wonderful thing for all SharePoint developers as that will further increase their value for not only be limited on SharePoint and its specialties.

We are even further looking to extend the SharePoint Framework usage across other areas of Microsoft 365 as it clearly is a framework and pattern, which works and has benefits for both Microsoft and external community.

Considering that SharePoint 2019 will also have native support for SharePoint Framework and modern experiences, you should be gradually learning to modernize the used techniques and move away from the classic customization patterns.

SharePoint Framework bypassed SharePoint add-ins from usage perspective in less than a year from the general availability, which is a massive achievement.

You are also coordinating the SharePoint Dev PnP team. In the meantime, it is difficult even to count all the PnP projects and guidance. What is next with PnP, what are you guys doing, what can we expect?

PnP team really consists from Microsoft internal and external people who are actively contributing on the SharePoint dev community to our official samples and documentation. There’s plenty of on-going activities where we spent our times, but the most interesting ones are most like the open-source end-to-end modern portal guidance (reference solution) and .NET Standard version of PnP CSOM Core and PnP PowerShell. Not obviously taking anything away from other community initiatives which are running under the PnP umbrella.

Check more details around the SharePoint Dev community from http://aka.ms/sppnp.

SharePoint online customizations are skyrocketing with SPFx and PnP libraries. It is a good time to be a SharePoint dev again. Can you tell us something about those numbers, and that do they mean?

Unfortunately, I can’t share direct numbers in this interview, but looking on the SPFx adoption, this was exactly what the SharePoint developers were waiting and hoping. SharePoint Framework bypassed SharePoint add-ins from usage perspective in less than a year from the general availability, which is a massive achievement. We are currently working on the store / ISV story around the SPFx in the SharePoint engineering which will absolutely make things even further interesting.

What does it though mean for SharePoint developers? – It does mean a renaissance of the SharePoint development and increasing the career opportunities for SharePoint developers as we generalize the development patterns with industry standards. You can take advantage of the latest web techniques and also therefore you will no longer be limited on the SharePoint as a platform. It’s win-win for all sides.

When will we see Graph API fully incorporating all SharePoint endpoints and features? What should someone, as a SharePoint dev use now to be futureproof: Graph or SharePoint REST APIS?

This is really interesting question which many sides has so to consider. Microsoft Graph API surface is growing all the time and we are also adding new APIs towards SharePoint, but to be able to expose something in Graph, services will need to have their native APIs as well. SharePoint REST API surface is massive, and we will never see the full API surface exposed through Graph, but we will certainly see more and more typical APIs exposed there. Graph also concentrates more on the actual content, rather than configurations and settings, which then are exposed in the native APIs – like regional settings or list configurations.

Will we expose more SharePoint capabilities in Graph? – absolutely. Will you still need to go to REST APIs in certain scenarios – Yes. Are we looking into making using Graph APIs easier with SharePoint Framework? – Yes.

Graph will be playing bigger and bigger role in here, but will never completely replace SharePoint REST APIs.

How in the world did you come up with “Sharing is caring” slogan?

To be honest, this is partly an insider joke or when I was still working as a Microsoft Services consultant with customer projects, our SharePoint consulting team used that as the thinking method for everything what we do. We adopted this in the PnP team early on and much later heard that it’s trademarked by American Red Cross. After consulting our MS legal team, we were though allowed to keep on using it.

That slogan though does work perfectly with the open-source thinking. Whole point of the thinking is that we are so much more powerful and skillful if we work together rather than compete between each other. I give some of my skills and experiences for others and hoping to learn from their skills. This way of thinking makes the community collectively much stronger and wiser. Thanks everyone for your sharing your learnings to me as well!