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.
My name is Paul Papanek Stork. I'm the owner and principle architect at Don't PaPanic Consulting. I specialize primarily in consulting on Office 365, SharePoint, SharePoint online and Dynamics CRM.
So, I've been working with SharePoint since 2004. We won't count in the predecessor products... I went all the way back to Site Server, Commerce Server, the first edition! Been working with SharePoint since SharePoint 2003 and I've always kinda straddled the fence, so I've been both an IT pro and a "dev" all these years and do a little bit of both.
So, I haven't spent as much time as I would like. Most of the work that I do nowadays is more architecture and governance and best practices. But, in order to do things like migrations from older systems to newer systems you have to keep up to date with how you do customizations and how you do development work in the new environments. I've been playing around with the SharePoint framework since it came out in beta about a year ago ... Haven't actually done a full project on it yet, so it's all been playing with it in the lab, just trying to learn how it works.
So, I like the Roadmap. I'm really looking forward to the release of what the Roadmap calls Feature Pack 2 for on-premises. I think that's one of the spots where things are really missing at this point. SharePoint Framework has been out in beta and now released for over a year, and there still isn't even a preview beta for on-premise that I'm aware of. I do a lot of work in the hybrid side of the world and having a different development story for on-premises versus in the cloud is a real problem in a hybrid kind of environment. So I'm really looking forward to the release of that particular piece. Also, looking forward to having the extensions go full term. A lot of the work that I have done in the past in server side development, leaned in the direction of event receivers and really looking forward to being able to do some more things with things like web hooks and so forth, using extensions to get into that kind of Framework.
So you'll hear this again when we get to talking about if you have any complaints about it. The piece I'd really like to see them add is something that plugs into the traditional tooling. Not so much that ... it'd be nice if they could develop something where you could actually write in C# and have it translate, but I won't hold my breath for that. But at least the ability to work directly in Visual Studio and have it compile and deploy from there instead of having to go to a completely different tool chain. I know there is a community effort at this point to do some stuff for Visual Studio, but it would be nice if that was officially supported.
So the one thing I would change is essentially what I just said, I'd really like to see direct Visual Studio's support for the ability ... Yeo and Gulp and all of the new tool chain is just ... It's just too much of a learning curve. It's bad enough that you're having to learn a whole new language with TypeScript, but then to throw in a whole new set of tools ... It's not that they're bad tools, but the first time that I looked at Yeo and I saw that little face sticking out at me from the character arrangement, I'm going wait, when did we go back to the mainframe world, because that's the way we used to do things. It would be nice to have something that was implemented in an IDE instead of being completely command line driven.
I think the biggest challenge and this has been for me and I think it is gonna be the biggest challenge for most developers, is the tool chain. It's just a very, very steep learning curve. Developers, especially traditional developers, are gonna go through a fairly steep learning curve already just to get off of server side languages and on to TypeScript and then to throw a whole new development tool chain at them, just really makes it insurmountable. A lot of people just don't go there because it's just too much to take in.
So, I have mixed feelings about the future of SharePoint Framework. I do think it's going to stick around. I think it is headed in the right direction. One of the pieces that I would really encourage Microsoft to look at is moving it out of the realm of just doing document object model manipulation of web parts and being able to do something that can manipulate the entire page. I don't think you're going to see that, but I do think you're gonna see a lot of additional extensions to extend the tooling out to other things, like the extensions that are currently in preview, something to get it remote, event receivers, some better story to tie into server side code and remote systems, like provider hosted apps. That's where I think you're gonna see it headed. I think they're going to avoid going to manipulation of the full page object model, which is kind of a shame, but that would lead people to start doing complete rewrites of the look and feel of the page. Which is where I think a lot of people want to go and where Microsoft would just as soon they not go.
Did you like this installment in the series? Let us know what you think in the comments below and share it on social media!