This is one installment in a series by Voitanos asking experienced SharePoint developers to share their thoughts on the new development model for SharePoint - the SharePoint Framework. In this series, we ask each person a series of questions and let them share their thoughts.
Hi, my name is Vincent. I'm based in Montreal, Canada. I work for 2toLead as an Office 365 and Azure developer. And I'm also an Office Service and Services MVP for three years now. I've been working on SharePoint for a couple of years now.
So I started working of SharePoint ten years ago would say, first as an IT Pro actually and the biggest thing I liked about SharePoint is, to understand properly SharePoint, you have to do both IT Pro and developer. So this is why I also had some developer background way back then in PHP. And this is why I like SharePoint. So, I started learning .NET and SharePoint development and I got into there. And well, basically, I'm still there ten years after. So yeah, this is my background.
So, I don't know how many hours I spent of the SharePoint Framework. I would say like, more than a year ago, at the MVP Summit, I was looking into that, here and there. And then I was playing with it, and trying to understand what was technology and how it was working. And, so, I would say a couple of months at least and a few dozen hours, at least. But the great thing about the SharePoint Framework is it's based on modern technologies. So, if you know webpack, Gulp, and TypeScript, you already know some of the stuff. And I already had experience on both things before playing with the SharePoint Framework.
I think it's great effort from Microsoft at large to transition a very old product, if you were to take it in IT terms and IT years, into the modern world development and so on and so forth. And, also, into open-source, and it has been a tremendous change. I think it's a great promise. The goal is novel. And we still have a long way to get there, though. We only have the web parts for now, and last week we announced the command extensions and so on and so forth. And we are adding little by little but we still have a very long way to go.
I like the roadmap because it captures a lot of things we've been asking for many years into a SharePoint space. For example, when you think about ALM and DevOps processes, which I've been talking about quite a few times now and in the past, in the SharePoint space, I mean. I like the fact that they finally understood that we need that stuff. We need API's. We need tooling. We need proper documentation around it and they're working on providing it. I might be a little bit impatient. I would have liked to have seen that before, maybe around the add-ins idea, so on and so forth. But, I like the roadmap, and also, access to the graph, and so if they have a bunch of our things that make a lot of sense in today's environment and development patterns.
I think the greatest change we made, so far, compared to the other development models is enabling unit tests first. So, whenever we create a new SharePoint Framework project, a new SharePoint Framework web part, day one, you get unit test report, which we never had in SharePoint and which was super costly and so we never did it, to be honest. And, I think it's going to be a great addition to our tooling and methodologies and so on and so forth. To make sure we ship quality over quantity or whatever we used to do.
It's tough question, I would add many things. The first one would be, probably, stuff around the provisioning, with the full trust solutions, add-ins, so on and so forth. Historically, we've always have been able to provision and establish lists and whatever you name it. And we don't have that in SharePoint Framework, which is a bit confusing. Of course, there is the PNP provisioning initiative. But, so far, I haven't seen any announcement or any information about it and I would like to have that. Also, like to have stuff around the [Microsoft] Graph, around ALM, and so on and so forth. But maybe I'm impatient sometimes.
The one thing I would change is probably the way they interact with the community. I get the fact that you have two things coming into play into a SharePoint Framework. You have the SharePoint Server bits that are part of a product, and that's Microsoft code and we have to keep it on their end. But then you have the SharePoint Framework bits that are supposed to be open-sourced and they are based on open-sourced tools. So, I would like to have seen, way earlier, the source code of the framework open-source so we could help them moving forward and getting faster. And I think, right now, they are not benefiting that and it's lacking in the framework itself.
So, from a SharePoint developer's perspective, I think the biggest challenge around the SharePoint Framework is the transition from service and technology's non-open-source stack and backend development to something which is more open-source, something which is totally different from what we were used to. So the learning curve for SharePoint developers is big. But that comes also with another perk, is I will be able to talk with my other open-source developers' friends and they will be able to be involved with what I am doing. So, I think it is kind of a trade off. But, it's hard for former SharePoint developers to transition to that, so far.
So my personal thoughts on that is, I think, started the transition a couple of years ago, they started seeing that SharePoint was more and more a service, and less and less of a platform. A couple of years ago they kept that message going on over the years. And also, when you take into account Microsoft teams as a platform, to me it would make sense somehow that this work we're doing on the framework and with SharePoint and the work which is done in teams should connect at some point and be almost the same thing. If you take aside branding and so on and so forth, what you want to support, is you want to enable users to do stuff. And everything is going to be in teams. So, not only SharePoint, but planner, notes, and so on. And if you want to enable users, the more services you can leverage out of the box and the more content you can provide out of the box, the better it is going to be.
So, my guess would be, SharePoint is going to be the API, and teams is going to be the integration platform. So, that's my personal guess.
If I had any advice, it would be probably for Microsoft to provide guidance around full trust solutions, add-ins, frameworks, and also the future around that, because a lot of people are asking a lot of questions around it and we don't know what we can leverage at what point in time now. But what they will be able to leverage into the future is how they should transition for different scenarios, this scenario and that scenario. Also, having some kind of support for the backend services into a framework would be good. Maybe, include a Docker template or ARM template for Azure or whatever it is so we could provision stuff to do batch jobs, to do queuing and the heavy lift and shift on the backend. Would be awesome to have that in the framework as well.
Did you like this installment in the series? Let us know what you think in the comments below and share it on social media!