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.
I'm Eric Shupps, SharePoint Server MVP, President of Binary Wave.
I've been doing SharePoint development since the dark days of the Tahoe Project before it was called SharePoint. So I've been around awhile through the early 2000 revs into 2007, and all the way now into 2016 and the Office 365.
Well, I started working with it in the early beta bits last year and worked with it through GA, and working with some of the various pre-release things that come out. So I've had some fairly good hands-on time with it so far.
I like that the Framework brings extensibility without all the overhead of working on the server. You don't have to have a fully installed dev environment, you don't have to be running all the heavyweight server stuff. It's something you can spin up. You [Andrew Connell] and I work on our Mac Books. We can deploy code from our Mac Books. Folks can work on Linux or whatever flavor they want to of that, or if they want to stick with their traditional Windows environment they can do that as well. But there's no server-side install, it's direct to the client, and it's all done in client-side technologies. I think that opens up the platform to a lot of people who weren't prepared for the very steep learning curve for traditional SharePoint development.
I like where they're going with it. If the team can execute on their vision of bringing a client-side extensibility model to where we stand on Office 365 and hopefully SharePoint on premises today ... if they can bring those pieces together, which is a big ask considering the breadth and width of the server-side APIs and where we've been with the add-in model and what not, but if they can really bring these things together I think we've got something really powerful that will give us capabilities that we've never had in the cloud and quite frankly that other cloud platforms don't have, and then translate that down on premise you get a pretty powerful story.
My impression of the road map is they've set a pretty ambitious agenda. I think they were smart to go with web parts out of the box as a basic extensibility concept. It's something we're sorely lacking in the add-in model that they focus their attention on, which is good. I think when we see the new publishing experiences people are really gonna like those, and of course, those are built on top of the Framework, so they're using their own toolset to deliver a new set of capabilities. I'm really excited to see where that goes. And if they can further extend that to give us some of the capabilities in the cloud that we have on premise in terms of overall extensibility, I think that's a really good direction for them to go. It's a lot of work to pull of if they can make it happen, but I think they're going in the right direction.
Well, it's interesting you should ask that, because the one thing that's missing from the tool set is integration with ID of choice from most SharePoint developers, and that would be Visual Studio. I love the new tool chain, and I like the VS code and everything being done with modern web technologies, that's great, but the target base for SharePoint development is and always will be within the enterprise. So I would ask people to stay tuned. We're working on a community project that hopefully will address those concerns for folks, and bridge that gap between the enterprise and the pure web development community.
Change would assume that we have the ability to go in a different direction, and I'm not really sure that we do. I think it's too early, in other words, to say what would we change or what would we do differently about what we have. They've taken a direction, for a lot of different reasons, to go with this modern web stack in terms of development. That's going to be very confusing for a lot of people, but they didn't really have an option in that. So we can say "Oh we'd like to see that change, we'd like to see it go back to a traditional server-side model", but that's not possible, nor do I think it's actually the right thing to do at this point.
I think there's ... in order to get this stuff out, to not have the traditional, we gotta wait three years for a new platform to come along, and for them to tool it, and support it and all that. We're beyond that now. So, I think people just need to be patient and let the process mature. For those who are having struggle adapting to it, yeah that can be a steep curve if you're a traditional server-side .NET developer, but I would encourage people to focus less on the tool set and more on what you can get out of the product, especially as it matures more and we get more capabilities.
People are going to struggle, there's no question about it, but when we look back people struggled with building web parts in 2007. People forget that there was a day where we didn't have any tooling, where we were running makeCAB, and making our own Diamond Directive files to build these WSP things. There was no tooling. Now it's easy cause it's all baked into Visual Studio, but it wasn't back then, and we're kind of in that same boat again. Although I would argue that the tool chains, although they may be unfamiliar, actually fairly robust within the web development community ... so there's going to be a period of transition that may be a little rough. But on the other side of that, I think people will like what that gives them in terms of overall capabilities.
In terms of future of the Framework, I think that the near-term future is pretty clear. They've identified a road map where they want to go with this thing. They've already started building their own modern experiences which are betting on heavily with this tool set. I think that secures the near-term future pretty well, 12, 18 months out. If they can execute, as I mentioned earlier, on their vision for this I think we have a pretty long runway for this Framework ... if people adopt. Now the community may not adopt, they may decide it's not for them, we have to be honest with ourselves that this is a fourth development model that we're working on. Some people have lost interest, for some it's just too much change, especially enterprise developers who are used to a very consistent tool set and ALM story. So we'll have to see, but if they can deliver us even a portion of the capabilities we have for customization at the server-side APIs, if they can do that in the cloud with all the other capabilities that Office 365 brings to the table, I think they've got some runway in this.
Did you like this installment in the series? Let us know what you think in the comments below and share it on social media!