Webinar recording
Summary
This is one installment in our series “In Own Words” 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.
Eric Shupps
I’m Eric Shupps, SharePoint Server MVP, President of Binary Wave.
What’s your background as a SharePoint developer?
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.
How much time have you spent with the SharePoint Framework?
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.
What is your impression of SharePoint Framework today?
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.
What is your impression of the SharePoint Framework roadmap?
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.
What is the one thing you would add to the SharePoint Framework?
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.
What is the one thing you would change to SharePoint Framework?
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.
What is the biggest challenge with SharePoint Framework?
The biggest challenge is definitely the tool chain. For most folks that’s a very hard bridge to cross, from where they were in ASP. NET in the C server-side type of development over to sort of this wild, wild West of JavaScript Frameworks and things that change so rapidly, and tool sets that seem to come and go with the setting sun. That is a challenge, there are certainly some Frameworks that are gaining adoption. I’m not sure that the tooling the way we have it now is following the trends there, about where most people are going in the web development community, but they’ve also made a choice not to block people out of using other Frameworks. Where is in the past it was .NET or nothing, and now we have I think more options available to folks. So that’s a good thing, I think.
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.
Predict the future - Where do you see the SharePoint Framework Going?
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.
Do you have any Advice or Words of Wisdom?
I would encourage people who are looking at it now, and wondering if they should or shouldn’t jump into it and work on it, to just go ahead and take the leap. You’re only gonna learn new things outside of our traditional bubble for SharePoint development, we’ve kind of been insulated for a lot of stuff, usually running behind the game. We’ve been telling people for years, get on the JavaScript bandwagon, learn this disconnected, remote API model, even if you’re writing .NET and CSOM, learn to break out that server-side chain … and I think this furthers that opportunity.
Find a Framework, or no Framework if you want, just write raw JavaScript in jQuery if that’s what you like to do, but get out of the comfort zone of the way we’ve traditionally built SharePoint stuff and look for new opportunities to learn the tool sets. Because if maybe you decide not to do SharePoint in a couple of years you’ll be ahead of the game a little bit in catching up where the rest of the development community is at, or be able to transition to other parts of the staff. Maybe you want to do teams development, or you want to do something inside of one of the other product areas of Office 365. So learning it now, getting ahead of the game, I think will pay dividends in the long run.